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MAGNETIC TAPE KEY 


BASIC 
This volume contains two files as described below. 


File 1 - Assembled object decks and JCL necessary to 
perform a HASPGEN (refer to Section 10 of 
this manual for information concerning use 
of this tape). 

Records - 417, ehaeaewers/eice: - 80, 
Records/block - 1, Blocks/file - 417. 


File 2 - Source decks for HASP-II, Version 3.0. 
Records - 50,343, Characters/block - 1600, 
Records/block - 20, Blocks/file - 2518. 


*Optional 


System/3 users only - 140 96-column cards. This deck. 


is a "Starter system" for the HASP MULTI-LEAVING Remote 
Job Entry support. ? 


*Optional material will be forwarded only when specifically 
requested. 
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Introduction 


‘The information contained in Volume 1 and 2 of the HASP System Supplementary Course 
Material was originally distributed as a one-volume document, 


| Volume 1 contains pages 1 through 590, Section 1 through 8. Volume 2 contains 
pages 1 through 594, Section 9 through 12. 


A Contents has been included in each volume for your convenience. 
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INTRODUCTION 


The HASP SYSTEM operates as a compatible extension to the MFT or 
MVT options of the Operating System for System/360 and System/370 
to provide specialized supplementary support in the areas of job 
management, data management, and task management. 


HASP appears as a transparent “front-end" processor to OS to, 
via the SPOOLing functions normally associated with OS input 
readers and output writers, act as an automatic scheduler 


and 
and 
and 
The 


operator of OS. Because of this relationship between HASP 
the Operating System, varicus other functional, performance 
Operational benefits can be included in HASP. 


use of HASP offers an installation the following advantages: 


IMPROVED PERFORMANCE - In many cases, because of the 
Singular, specialized use of resources by HASP, system 
performance may be improved. Any improvement is dependent 
upon the configuration and job mix and can only be deter- 
mined by actual measurement. (See Section 2 of this manual 
For additional details.) 


IMPROVED OPERATIONAL PROCEDURES - HASP acts as an automatic 
interface between the operator and OS, to perform various OS 
control functions previously done directly by the operator. 
Readers, Writers and Initiators in OS are started and sched- 
uled automatically by HASP. Also, many additional operator 
commands for controlling job flow and device operation are 
provided by HASP. (See Section 11 of this manual for 


additional details.) 


INCREASED SYSTEM FUNCTION - The use of HASP provides certain 


functions which are not otherwise available. These include 
dynamic task ordering based upon CPU - I/O characteristics 
(see Section 2 for additional details); the inclusion of 


relevant console messages in each job's output (see Section 7! 
for additional details); the capability of any job to intro- 
duce another job into the HASP queue via an internal reader 
(see Section 12.10 for additional details); an execution 
batching facility to pass jobs directly to a processing pro- 
gram such as a one-step monitor (see Section 12.13 for addi- 
tional details); many additional operational control functions 
(see Section ll for additional details); a priority aging 
technique (see Section 4.22 for additional details); a pre- 
execution volume fetch facility (see Section 11 for additional 
details); and various other functional enhancements. 


RESOURCE REDUCTION - Because of the dynamic direct-access 


allocation techniques utilized by HASP, installations may, in 
general, reduce the number of direct-access volumes required 
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for SPOOLing functions as compared with a non-HASP SYSTEM. 
The size of the OS SYS1.SYSJOBQE data set may also be 
reduced since all job queueing is performed by HASP. 


Certain installations may actually reduce system main storage 
requirements (increase problem program space available) by 
adding HASP to their system because of the OS functions 
replaced by HASP. In any case, the space required for the 
HASP partition or region will be at least partially compen- 
sated for by the elimination of duplicate functions. 


@ LOW-ENTRY, HIGH-PERFORMANCE REMOTE JOB ENTRY - For a nominal 
increase in the size of HASP, an installation can utilize the 
HASP RJE support for a wide variety of workstation devices. 
Support for Binary~Synchronous, CPU workstations employs an 
advanced technique called MULTI-LEAVING which provides for 
Simultaneous operation of all devices on a remote workstation. 
A subset of the HASP operator command language is provided to 
all remote sites. Workstation programs are supplied for all 
supported CPU workstations. (See Section 12.11 for addition- 
al details.) 


@ TRANSPARENT OPERATIONS ~- HASP is, in general, transparent to 
both the Operating System and to user programs. Although 
a special SYSGEN is required, no actual modifications to OS 
are required to utilize HASP. Thus, the same generation of 
OS may be interchangeably used with or without HASP. Because 
of this transparency, HASP is generally independent of the 
OS release level or options selected and can be used as a 
stable base for local modifications to customize for local 
operational requirements. : 


Most standard jobs which operate under OS can be run with 
absolutely no change in a HASP environment. Most installations 
can, therefore, implement HASP with little or no changes to 
current user programs. 
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2.0 GENERAL DESCRIPTION 


HASP is a specialized program which operates in the same CPU 
with OS/360 to perform the peripheral functions associated with 
batch job processing. 


HASP is loaded as a normal OS/360 program and upon gaining 
control enters the supervisor mode via a special SVC routine. 
Control of all on-line unit record devices is assumed, the 
designated intermediate storage direct-access device(s) are 
initialized and job processing begins. The basic interface be- 
tween HASP and OS/360 is through the Input-Output Supervisor (IOS). 
The entry point of IOS is modified so that Input-Output requests 
to unit record devices are diverted to HASP rather than being 
physically executed by IOS. Jobs which have been previously read 
from physical input devices by HASP can now be passed to OS by 
Simulating a successful completion of the intercepted I/O request. 
In a similar manner, print and punch output from jobs being pro- 
cessed by 0S/360 can be intercepted and queued on intermediate 
storage for later transcription to unit record devices. 


HASP has four major processing stages which account for its four 
major external functions. These are: 


Ls INPUT STAGE - This stage reads jobs simultaneously from an 
essentially unlimited number of various types of on-line 
card readers, tapes and remote terminals into the system. 
These jobs are then entered into a priority queue by job 
class to await processing by the next stage. 


2% EXECUTION STAGE - This stage removes jobs based upon priority 
and class from the queue established by the Input stage and 
passes those jobs to OS/360 for processing. Input cards are 
Supplied as required to the executing program and print and 
punch records are received and written onto HASP intermediate 
storage. This stage can simultaneously control an essentially 
unlimited number of jobs being processed by OS/360. At the 
completion of a job, it is placed in a queue to await pro- 
cessing by the next stage. 


3. PRINT STAGE - The purpose of this stage is to transcribe the 
printed output generated by jobs in the previous stage to 
printers. An essentially unlimited number of various types 
of printers and remote terminals can be operated simultaneously. 


4, PUNCH STAGE - This stage transcribes the punch output generated 
by jobs in the execution phase to punches. An essentially 


unlimited number of various types of punches and remote 
terminals can be operated simultaneously. 
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All of the these processes are controlled by re-entrable code 
so that no additional code is required to support multiple, 
Simultaneous functions. Since all of the above functions can 
occur simultaneously and asynchronously, a continuous flow of 
jobs may pass through the system. | 


Following are some of the more significant algorithms employed 
by HASP to improve function and performance: 


SPECIALIZED DIRECT-ACCESS STORAGE ALLOCATION 


HASP, 


through the use of an allocation bit map in main 


storage, dynamically allocates space for intermediate 
storage on a record basis, within definable track groups, 
for jobs. The use of this technique offers the following 
advantages: | 


ae 


UNIT 


Disk-arm motion and interference is minimized by | 
dynamically allocating space based upon the position 
of the access mechanism. 


Disk area fragmentation is automatically eliminated 
by allocation of the smallest poentee increment of 
apace: 


The data for a single data set can be spread across 
multiple direct-access volumes. In addition to further | 
optimizing arm motion, this capability allows for the 
Simultaneous use of multiple selector channels to 
increase the data rate for a given job. | 


Since space is allocated only when required, there 
will be no unused space as a result of over estimated 
output requirements. 

The release of previously used space is accomplished 
by a simple algorithm which requires no I/O operations. 


RECORD DEVICE COMMAND CHAINING 


While operating any reader, printer or punch, rather than 
handling each record separately, HASP constructs a chained > 
sequence of channel command words to pass to the channel. 


Thus, 


instead of the overhead of an EXCP and the ensuing 


interrupts for each record transmitted, only one EXCP and 
associated interrupt is required for a series of records. 
For example, when reading a job into the system, HASP might 
chain 40 commands together to instruct a card reader. This 
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would cause the next 40 cards to be read into memory without 
requiring the execution of any CPU instructions. 


TRANSPARENT BLOCKING 


All input, print and punch for every job is automatically 
blocked by HASP to improve performance. Since all deblocking 
is also done by HASP, any program even if designed to operate 
with unblocked records can benefit from the blocking. Also, 
because all blocking and deblocking is done by HASP, problem 
programs require buffers only the size of a single card or 
line. This can reduce a program's partition or region require- 
ment by several thousand bytes over normal full track blocking. 


DYNAMIC BUFFER POOL 


HASP maintains a dynamic area of memory which is allocated as 
required. This technique allows not only multiple data sets 
of a job, but multiple jobs to share this area, thereby 
insuring optimum use of storage. © 


EXECUTION TASK MONITOR 


A Significant item contributing to system performance is the 


correct ordering of dispatching priorities of jobs in rela- 
tion to their CPU-I/O utilization ratios. It is obviously 
straightforward to manually set the dispatching priorities 


of two jobs, one of which is completely I/O-bound and the 


other completely CPU-bound. It becomes more difficult to 
determine relative priorities of multiple jobs with varying 
degrees of CPU-I/O ratios and impossible to determine prior- 
ites for multiple jobs which eensrantey Change from CPU to 
I/O bound or vice versa. 


HASP provides a feature which, at frequent intervals, examines 
each eligible job and dynamically re-orders the OS dispatching 
chain based upon the measured CPU-I/O characteristics of the 
jobs during the previous interval. This capability relieves 
an installation of the responsibility of attempting to assign 
job dispatching priorities while insuring the optimum ordering 
of jobs being processed by the Operating System. 
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(The remainder of this page intentionally left blank.) 


HASP 
3.0 HASP STRUCTURE 


The primary goal in the design of any execution support system such 
as HASP must be the efficient manipulation of the various resources 
required for processing. The first design steps must then include the 
determination of what resources will be required and the careful application 
of sound programming design techniques to achieve an efficient and 
consistent solution to the allocation of these resources. 

A study would reveal that HASP requires the Parewine resources: 

1. Main Storage 

2. Direct-Access Space 

3. Input/Output Units 

4. Central Processing Unit Time 

5. Input/Output Channel and Unit Time 
6. Programs 

7. jobs 

8. Interval Timer 

Since these resources are essentially the basic facilities provided by 
the Operating System, it would at first seem that these facilities would 
be sufficient to meet the requirements of HASP. Further studies show, 
however, that the philosophies of the Operating System's services are not 


always consistent with the design requirements of a system such as HASP. 
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For instance, the main sverage services provided by the Operating 
System are very flexible and edinpreneneive but fail to meet the require- 
ments of HASP in the following areas: 

& As requests for main storage are serviced, memory becomes 
fragmented in such a way that eventually a request for 
storage cannot be serviced for lack of contiguous memory 
even though the total amount of storage available far 


exceeds the requested quantity. 


® As the amount of available storage decreases, the 
requestor becomes more susceptible to being placed in 
an OS WAIT state or being ABENDed. These conditions are 


both intolerable to HASP. 


® The primary use of main eierace in HASP is for pieeeias 
space for input/output purposes. These input/output pur- 
poses require that an Input/Output Block be associated 
with each segment of main storage which the Operating 
System Main Storage Supervisor, only naturally, does not 
provide. This means that HASP would have to construct 


such a block for each main storage segment it required. 


{a 


HASP 


In a similar fashion the Direct-Access Device Space Manager 


(DADSM) provides flexible and comprehensive services for normal 





job processing requirements but fails to meet the requirements of 
HASP a the following areas: 
® Because of the data set concept employed by DADSM, 
the "hashing" or " fragmentation" problem described 
above also impacts the allocation of direct-access 


Space. 


@ The data set concept complicates the simultaneous 
allocation of storage across many volumes (for 


selector channel overlap). 


@ The DADSM limit of extents per volume tends to cause 
volume switching, and the associated time delays are 


intolerable to HASP, 


@ DADSM consists of non-resident routines which must 
be loaded for each direct-access space allocation 
service. daca of the frequent allocation requirements ; 
the associated overhead involved in the loading of these 
routines would degrade the performance of HASP toa 


certain extent. 
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Since the unit-record input/output units which the scheduler 
aliseates to the jobs being processed in other partitions must be 
available for ies by HASP, HASP must be responsible for the allo- 
cation of its own input/output units. 

_ The Operating System Task Supervisor is responsible for the 
allocation of Central Processing Unit (CPU) time to all tasks in the 
system. The different pinetions of HASP (reading cards, printing, 
punching, etc.) could i defined as individual OS tasks except 


for the following considerations: 


@ Defining each function as a separate task would 
- prohibit HASP from being used with anything other 


than a variable-task system. 


% Inter-task communication and synchronization is 
many times more complex than intra-task commu- 


nication and synchronization. 


The Operating System Input/Output Supervisor is responsible 
for the allocation of all input/ output channel and unit time. It 
completely meets all requirements and is used by HASP for all 


input/output scheduling. 
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The Operating System Interval Timer Supervisor provides complete 
interval timer management services but limits iieee services to one 
user per task. Since HASP has many functions which have aiuiesnests 
interval timer requirements, ae interface must be provided which will 
grant unlimited access to the OS Interval Timer Supervisor. 

The following sections describe, in detail, the allocation psenaiees 
and algorithms used in HASP to provide the allocation of the resources 


listed above. 
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3.1 ALLOCATION OF MAIN STORAGE 


The main storage requirements of HASP are as follows: 
@ Storage space for buffering card images and sant lines 
beeen intermediate ainecesaceeas storage devices 
and aniesrecerd devices. 
e Storage space for normally non-resident control tables 
during cniee when they are resident in main storage. 
® Sisase for console messages which have been gaened 
for output to or input from one enact operator consoles. 
e Storage for elements which reflect the status of all jobs 
| which are queued for any stage of processing by HASP. 
@ Storage space for non-resident processing routines (over- 


lays) during times when they are in main storage. 


The HASP Buffer Pool 





The first two requirements for main storage are provided for by the 


HASP Buffer Pool, a group of buffers with the following basic format: 
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Input/Output 
Block 
(IOB) 


buffer control 
information 


buffer 
~ work 
space 





Figure 3.1.1 - The HASP Buffer 


Since the use of this buffer always involves some input/output 
activity, a standard Operating System Input/Output Block (IOB) is pro- 
vided wie each buffer for the purpose of being used to initiate this 
input/output activity. 

The “buffer control information" area is an extension of the IOB used 
by HASP for input/output synchronization. 

The "buffer work space" is a fixed-length (set by HASPGEN) area into 
whieh data is read and/or out.of which data is written. 

In addition toa fixed number of buffers (set in accordance with region 
Or partition size), the buffer pool contains a one-word control field called 
the Buffer Pool Control Block which contains the address of the first avail- 


able buffer in the buffer pool. Each available buffer contains the address 


fh 
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HASP 


of the next available buffer with the last available buffer containing a 
zero widens . Ifno buffers are available, the Buffer Pool Control 
Block contains zero. 

The above technique is called "chaining," the buffers are said 
to be "chained," and the field containing the address of the next | | 
- element in the chain is referred to as the "chain field." Chaining 
is used throughout HASP for the maintenance of resources. 

To obtain an available buffer from the buffer pool, the Buffer Pool 
Control Block is tested for an available buffer. If one exists it is 
removed from the available anath by moving its chain address into the 
pool control block. 

To release a buffer to the available chain, the contents of the 
pool control block are moved to the chain field of the buffer, and the 


address of the buffer is placed in the pool control block. 


The Console Message Buffer Pool 


The third requirement for main storage is provided for by the 
Console Message Buffer Pool. This buffer pool is organized similarly | 
to the HASP Buffer Pool except for the format of the buffers which is 


as follows: 
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, chain field 






Figure 3.1.2 — The Console Message Buffer 


Since IOB's are provided for each console, it is not necessary to 
provide such a control block with eden ice 

The length of the work space is consistent with the maximum 
length of a console message. 

Buffers in this buffer pool are obtained and released by exactly 


the same procedure used in the HASP Buffer Pool. 


The HASP Job Queue 


The fourth requirement is provided for by the HASP Job Queue. 


For more information about this facility see section 3.6. 
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The HASP Overlay Area Pool 


The HASP Overlay Area is similar to the HASP Buffer in format; 
however, the size of the "work space" is set to accommodate the 
largest non-resident HASP control-section (CSECT). Although the 
fixed number of overlay areas (set by HASPGEN) are chained together, 
| control fields indicate the area status and contents for the purpose 
of sharing areas containing the same CSECT or for selecting an area 


to overlay with a new CSECT. 
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3.2 ALLOCATION OF DIRECT-ACCESS SPACE 


The direct-access allocation technique employed by HASP must 
meet the following requirements: 


It must use a minimum of CPU time. 
It must not use an excessive amount of main storage. 


It must not be susceptible to the "hashing" or 
"fragmentation" problem. 


It must be capable of allocating for any direct-access 
device which is supported by Operating System/360. 


It must be device transparent to the user. 


It must be consistent with the checkpoint/restart 
technique used by HASP. 


The HASP Track Address 


The standard Operating System track address is defined to be an 
eight-byte field with the following format: 





M = Module 
BB = Bin 

CC = Cylinder 
HH = Head 

R = Record 


Figure 3.2.1 - The Operating System Track Address Format 


For the purpose of HASP, this track address can be reduced to a 
four- byte field with the following format: 





M = Module (DEB extent number) 
ha = True Track Number 
R = Record 


Figure 3.2.2 - The HASP Track Address Format 
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The reduction in the length of the track address permits it to 
be kept in a single word of storage or in a general purpose 
register simplifying the handling of the track address. 


The HASP Master Track Group Map 


The HASP Master Track Group Map is a table which represents the 
sum total of all track groups or logical cylinders available on 
all HASP direct-access SPOOL volumes. (A track group contains 
one or more tracks which are considered a single resource.) 
Each bit in the HASP Master Track Group Map represents a single 
track group on one direct-access volume. If the bit is one, it 
indicates that the corresponding logical cylinder is available 
for allocation; if the bit is zero, the logical cylinder is not 
available to HASP or has already been allocated by HASP. 


The HASP Job Track Group Map 


The HASP Job Track Group Map is identical to the HASP Master Track 
Group Map except that one word has been added to the front to save 
the last track address which was allocated to the particular job 
with which the map is associated. The bits in the Job Track Group 
Map represent the same track groups as the bits in the Master Track 
Group Map except that a one bit indicates that the respective track 
group has been allocated to the associated job and a zero indicates 
that the group has not been allocated to the job. 


last track address 


track group 





Figure 3.2.3 - The HASP Job Track Group 
Two Job Track Group Maps are associated with each job. One repre- 
sents the track groups used to contain the input data (SYSIN), 


and the other represents the groups used to contain the output 
data (SYSPRINT and SYSPUNCH). 
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Direct-Access Space Allocation Procedures 


When the direct-access space allocation subroutine is entered, it 
first examines the first four bytes of the appropriate Job Track 
Group Map to determine if a new track group is required. A new 
group is required whenever no tracks have been allocated to this 
job (the last track address is zero) or if all of the tracks in 
the last group allocated have been used. 


If a new track group is not required, the record or head field of 
the last track address is incremented to provide a new track 
address. 


If a new track group must be allocated, the Master Track Group 

Map is scanned for an available group. When the next group to 

be allocated is determined, the appropriate bit in the Master Track 
Group Map 1s set to zero, and the corresponding bit in the Job 
Track Group Map is set to one. A track address is then constructed 
to represent the first track in the new group, and this track 
address is saved in the first four bytes of the Job Track Group Map. 


When any direct-access input/output operation is initiated by HASP, 
the HASP I/O interface saves the cylinder which was referenced 

by module. When a new track group must be allocated, the allo- 
cation routine first tries to allocate a group corresponding to 

the last cylinder referenced on each module. If these groups are 
not available, the routine attempts to allocate within one cylinder 
of the last references. If track groups within these cylinders are 
not available, the routine tries to allocate a group within two 
cylinders, and so on, until the entire track group map has been 
examined. 


Direct-Access Space De-Allocation Procedure 





To de-allocate the direct-access space allocated to a particular 
function, it is necessary only to "OR" the track group map portion 
of the Job Track Group Map associated with the particular function 
into the Master Track Group Map. This will reset to one all bits 
in the Master Track Group Map which correspond to the track groups 
which have been allocated to the particular function. 


Allocation of Direct-Access Space - Page 3.2-3 


19 








The HASP Device Control Table (DCT) is used by HASP to allocate 


all input/output units. It has the following basic format: 


device type | 


other 
control 
information — 


| device name | 










Figure 3.3.1 — The HASP Device Control Table (DCT) 


The "status" field is used to indicate whether the device is available 
and whether it is in use. 

The “device type" field specifies whether this DCT sdpresents a card 
reader, printer, punch, or other type of I/O device. 

The “other control information" field aontaing such information as 
the Data Control Block (DCB) address, the chain sddreus: indications of 


operator commands, and other fields for. synchronization purposes. 
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The "device name" field contains an eight-byte EBC DIC device 
name (such as READER1) which is primarily used for console messages. 

The "work space" is a device dependent area used by some devices 
for extended control of the device. 

All DCT's are chained together for allocation purposes. They are 
initialized by the HASP initialization phase if the associated devices 
are attached to the system. 

Input/Output Device allocation consists of "running" the DCT 
chain and looking for a DCT of the specified type which is available 
and which has not been allocated. If one is found, the "in use" bit 
is set to one to indicate that the device has been allocated. 

De-allocation consists of setting the "in use" bit to zero. 

The Device Control Table is also used as a parameter list whenever 


Input/Output activity is initiated through the HASP I/O interface. 
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3.4 ALLOCATION OF CENTRAL PROCESSING UNIT TIME 





The Operating Secten controls the allocation of Central piocaseing: 
Unit (CPU) time to different tasks through the means of a Task Control 
Block (TCB) chain. In a similar fashion, HASP controls the siiéeation ; 
of CPU time to the different functions within HASP through the means 
of a precessor Control Element (PCE) chain. The basic format of the - 


Processor Control Element is as follows: 


| OS 
| save 
area 
event wait field 
chain field 


processor 
work 
space 






Figure 3.4.1 — HASP Processor Control Element (PCE) 


Whenever a particular function is being processed, general purpose 
register 13 always contains the address of the Processor Control Element 
which is allocating the time to that function. For this reason the first 


eighteen words of the PCE are a standard os register save area. 
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The "event wait field" is a two-byte field which describes the 
dispatchability of the Anton under the control of this PCE. If this 
field is zero, the function is dispatchable. If this field is non-zero, 
the function is not dispatchable and the bit which is one specifies 
upon what event the function is "waiting". 

The "chain field" contains the address of the next PCE in the PCE 
chain. 

The "processor work space" is a variable length area which is used 
by the program processing the function as a scratch area. 

HASP searches the PCE chain looking for a PCE which is dispatchable. 
When a dispatchable PCE is located, the general purpose registers are 
loaded from the PCE/OS save area and control is passed to the location 
specified in register 15. 

When control is returned to the dispatching program, the general pur- 
pose registers are saved in the PCE and the search for dispatchable PCEs 
continues. Ifa notable event occurred since the last PCE dispatch such | 
as the freeing of a common resource or the "posting" of a specific event, 
the search starts at the beginning of the PCE chain; otherwise, it starts 
with the PCE following the last dispatched. The program returning control 
to the dispatching program must set the return address in register 15 Warore 
returning. 

When no PCEs are found to be dispatchable, the HASP task enters an 
OS WAIT state to allow the Operating System to allocate CPU time to other 
tasks, 
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3.5 ALLOCATION OF PROGRAMS 


The programs of which HASP is composed can be divided into 


the following classifications: 


® The Dispatcher 

® Processors 

@ Control Service Programs 
@ Miscellaneous Programs 


The Dispatcher is the dispatching program described in Section 
3.4. Its function is to distribute CPU time among the various processors 
described below. 

Processors are programs which control the execution of various HASP 
functions such as reading cards, printing, punching, etc. With each 
processor is always associated at least one Processor Control Element 
which esuees the dispatcher to give control to the processor and allows 
the processor to synchronize with various HASP events. The PCE work 
space also permits the processors to be written e-enteenly such that by 
defining more than one PCE for a given processor, the processor can control 
an essentially unlimited number of functions simultaneously. For instance, 
by defining ten PCEs for the Print Processor, up to ten printers can be ser- 
viced simultaneously utilizing and requiring only one copy of the processing 


program. 
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The Control Service Programs are subroutines used by the processors 
in accomplishing their functions. By using the PCE/OS save area, the 
control service programs can maintain the re-enterability of the 
processors. 

Miscellaneous Programs are those special purpose programs which 
do not fall into any of the other three categories, such as the HASP 
Initialization Program. They are executed only once and need not be 


considered in the normal HASP job flow. 
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3.6 ALLOCATION OF JOBS 


HASP maintains its job pointers in the HASP Job Queue, a table of | 


elements with the following basic format: 


Figure 3.6.1 — The HASP Job Queue Element 












The "priority" represents the dynamic priority of the job within the | 
HASP system. | 
The "type" represents the function for which the element is queued 
or the function in which the job is currently being processed. 
The "job number" is the number sequentially assigned to each job 
by HASP as it enters the system. 


The "chain address" is the address of the next element in the chain. 
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The "JCT track" is the track address of the HASP Job Control Table 
described below. 

Two chains are maintained in the Job Queue. The first chain 
represents those jobs which are currently awaiting processing or being 
processed. Elements in this chain are chained in the order of their 
priority. The second chain represents the inactive or unused queue 
elements. 

To add a job to the job queue, a queue element is obtained from 
the inactive chain, initialized with the information shown in figure 
3.6.1, and inserted into the active chain according to its priority. 

To obtain a job from the job queue, the active chain is searched 
for an element of fie specified type. When found, the "type" field is 
modified to reflect the fact that the job is now being processed. 

To return a job to the job queue, the element is moved from the 
active chain to the inactive chain. Since the priority is of no concern 


here, the element is placed at the head of the chain. 


The HASP Job Control Table (JCT) 


The HASP Job Control Tabie contains all of the information necessary 


to process the associated job in the following basic format: 
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data from 
JOB Card 


accounting 
information 


first input track 


input job 


track group map 


output job 
track group map 


work space 


output data 
set tracks 





Figure 3.6.2 - The HASP Job Control Table (JCT) 


The HASP Job Control Table fe normally resident ona direct-access 
intermediate storage device. Once the HASP Job Queue Element is 
obtained, the "JCT track" in the element can be used to initiate a read 
into a HASP Buffer. Once this read has been completed, all information 


necessary to process the job can then be obtained. 
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3.7 ALLOCATION OF OVERLAY AREAS AND NON-RESIDENT CONTROL SECTIONS 


Portions of the various programs of which HASP is composed are 
organized into non-resident control sections (CSECTs) and stored 
in an overlay library (OLAYLIB) on a direct~-access volume. These 
control sections contain HASP re-entrant subroutines and/or data 
which may be requested for use by a Processor. 


The user obtains an Overlay Area by requesting from the overlay 
control service program for use of a non-resident CSECT. If the 
CSECT requested is in main storage, the user is allowed to use 

the Overlay Area for processing. If, however, the CSECT is not 
already in an area, an area must be selected to hold the requested 
CSECT. The requesting Processor is made to “wait" until the 
requested CSECT is read from direct~-access into main storage. 


The algorithms for Overlay Area allocation cause multiple users 
of the same CSECT to use only one area, into which that CSECT is 


read. Competition for areas is resolved partially by the priority 


associated with each overlay CSECT. However, a "pre-empting" 
(roll) algorithm prevents any Processor from being indefinitely 
delayed, even if the system has only one Overlay Area. 


The user releases an Overlay Area by requesting that overlay 
services remove his PCE from association with the area. 
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4.0 HASP PROCESSORS 


This section contains detailed internal information about each of 


the HASP Processors and is intended primarily for use by system 
programmers. 
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INPUT SERVICE PROCESSOR 


INPUT SERVICE PROCESSOR - GENERAL DESCRIPTION 


The functions of the Input Service Processor are as follows: 
. To read card images from an input device. 


. To detect and scan JOB cards, extracting parameters for 
job accounting, job control, and print and punch identi- 
fication. 


- To detect and process other control cards such as the 
PRIORITY, MESSAGE, ROUTE, SETUP, COMMAND, DD*, and DD 
DATA cards. 


- TO aSSign a unique HASP job number to each job. 
- To log jobs into the HASP System. 


- To assign job priority based upon PRIORITY card or JOB 
card parameters. 


-. To generate, from cards read, a JCL file and input data 
files, and to record these files on direct-access storage 
device(s) for later use by the Execution Control Processor 
(see Section 4.2). 


- To generate HASP Job Control Tables, Job Queue Entries, 
and other HASP control blocks required for later Job proces- 
Sing. 


- To queue jobs for pECceeenrd by the Execution Control 
Processor. 


The Input Service Processor is coded re-enterably in such a 
way that it can accept jobs from a number of different input 
devices (with different hardware characteristics) simultane- 
ously. The re-enterability is attained by retaining all 


storage unique to a job in the Processor Control Element 


(see figure 4.1.1) which must be unique for each input device. 
INPUT SERVICE PROCESSOR - PROGRAM LOGIC 


The Input Service Processor is divided into three phases, 13 
subroutines, and three non-process exits. This section will 
give a functional description of each of these phases, sub- 

routines, and exits to aid the System Programmer in gaining 

a working knowledge of the processor. 
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PHASES 
Phase 1 - Processor Initialization 


The Initialization Phase, which is written as an overlay seg- 
ment, begins by attempting to acquire an input device. If 

no input device is available, the processor is placed in a 
HASP SWAIT state until a device is made available; whereupon 
the entire procedure is repeated until an input device is 
available. Upon acquiring an available input device the 
processor continues by acquiring a Device Control Table (DCT) 
for the direct-access device(s) and a HASP buffer for use as 
an input buffer. 


If the input device is not a remote terminal, a chain of 
Channel Control Words (CCW's) is then constructed in the 
input buffer which will be used to read 80-byte records from 
the input device into the rest of the input buffer.. These 
CCWs are constructed in such a way that the input records 
will be read into adjacent areas in the input buffer with as 
many cards being read as the buffer will hold. The initiali- 
zation of the PCE Work Area is then completed and control is 
transferred to Phase 2. 


If the input device is a remote terminal, transmission is 
initiated by calling upon the Remote Terminal Access Method 
to open the Remote Terminal Device Control Table. Control 
is then passed to Phase 2. 


Phase 2 - Main Processor 


The Main Processor Phase reads cards from the input device, 
scans each card to detect HASP control cards and processes 
these cards as follows: 


/*control card--The control card scan routine (HASPRCCS) is 
called to process the control card and take any appropriate 
action. 


Job Card--The JOB card scan routine (HASPRJCS) is called to 
terminate the previous job (if any), to scan the JOB Card, 
and to initialize the PCE work area for the processing of 
the following job. 


DD* or DD DATA--A track address is obtained for the first 
data block of the input data set. A dummy card is added to 
the JCL file which contains the track address in columns 1-4. 
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This card is differentiated from other cards by setting the 
control byte (see figure 8.15.1). The DD* or DD DATA state- 
ment is then added to the JCL file in normal fashion. Control 
is subsequently turned back to the main processor to process 
the input data. 


When a hardware end-of-file is detected on the input device, 
or when "SDRAIN input device" command is entered by the opera- 
tor, control is given to Phase 3. | 





Phase 3 - Processor Termination 


Upon receiving control from the Main Processor, the Processor 
Termination Phase, which is written as an overlay segment, 
terminates the last job (if any), issues a rewind and unload 
command to the input device if it is tape, frees the input 
buffer, closes the input DCT if it is a Remote Device, releases 
the input and direct-access devices, and returns control to 
Phase l. 


SUBROUTINES 





HASPRCCS ~~ Subroutine to Process HASP /* Control Cards 


The HASPRCCS subroutine, which is written as an overlay seg- 
ment, is called whenever the Main Processor Phase encounters 
a /* control card. The control card type is first determined 
and then processing continues as follows: 


/*COMMAND Card ~- The command is listed on the opera- 
tor's console and then added to the Command Processor's 
input command queue. | | 


/*PRIORITY Card -- The previous job (if any) is termina- 
ted, the priority specified is converted to binary and 
saved, and the scan is continued with the next card. 

If the following card is not a JOB card, the message, 
"device SKIPPING FOR JOB CARD", is written on the 
operator's console, the effect of the /*PRIORITY Card 

is nullified, and the input stream is scanned for 
another /*PRIORITY or JOB card. 


/*ROUTE Card -- The appropriate routing byte is set to 

the value associated with the destination indicated. 

If an invalid field is encountered, an appropriate mes- 
Sage is issued, both to the operator and to the programmer, 
and further job processing is bypassed. 


SSA YO ae 
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/*SETUP Card -- The volumes to be mounted are listed on 
the operator's console and the job is placed in “hold" 
Status. | 

/*MESSAGE Card -- Leading and trailing blanks are remcved 


and the message is routed to the operator's console. 


If the control card type is not recognized, the card is ignored 
and treated like any other /* card. 


HASPRJCS--Subroutine to Scan and Initialize Job Control Information 


The HASPRJCS subroutine, which is written as an overlay segment, 
1s called whenever the Main Processor Phase encounters a JOB card. 
The previous job (if any) is terminated by calling the RJOBEND 
subroutine. The master job number is incremented and its new 
value is assigned to the current job. The job control informa- 
tion in the PCE Work Area (see figure 4.1.1) is initialized by 
scanning the JOB card and extracting parameters relative to job 
control. The first JCL block is initiated, and control 1s passed 
to the Job Initialization Subroutine: HASPRJBI. 


RSCAN - RSCANA -- Subroutine to Scan Parameters from JOB Card 


This subroutine has two entry points; the entry point: "RSCAN" 

is used to scan numeric parameters from the JOB card, while the 
entry point: "RSCANA" is used to scan alphameric parameters from 
the JOB card. There are also two returns from the subroutine. 

If return is made to the first byte following the Branch and Link 
(the call) instruction, it indicates that the final parameter on 
the JOB card was returned on the previous call and that there are 
no more parameters. If return is made to the fourth byte follow- 
ing the Branch and Link instruction, it indicates that parameter 
register "R1" contains the next parameter, right-adjusted with 
leading binary zeroes. If the parameter was a "null" parameter, 
"R1" will be zero. If this subroutine detects an illegal char- 
acter (such as a non-numeric character in a numeric field) or 
more than four characters in a parameter, control is transferred 
to the RBADJOBC subroutine. 


RCONTNUE -~ Subroutine to Validate Continuation Cards 





This subroutine validates JCL continuation cards by ensuring 
that columns 1 and 2 are punched with slashes and that column 3 
is blank. The start of the continuation card is located and 
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control is returned to the caller. If an invalid continuation 
card is discovered, control is passed to the illegal job card 
subroutine for further processing. 


REBCDBIN -- Subroutine to Convert from EBCDIC to Binary 





This subroutine expects to find numeric EBCDIC characters with 
leading binary zeroes in parameter register "Rl". There are 

two returns from the subroutine. If return is made to the 

first byte following the Branch and Link (the call) instruction, 
it indicates that the parameter register now contains the binary 
equivalent of the EBCDIC input. If return is made to the fourth 
byte following the Branch and Link instruction, it indicates 
that the parameter register was zero (null parameter) and con- 
tained no EBCDIC to translate. 


HASPRJBI -- Subroutine to Initialize Job Processing 





This subroutine, which is written as an overlay segment, re- 
ceives control from the JOB Card Scan Routine (HASPRJCS) and 
completes the initialization of the various control blocks for 
input job processing. A "job on" message is issued to the 
operator, the job's priority is assigned based upon JOB card 

or /*PRIORITY card parameters, and the job is queued in the 
active input queue. Control is then returned to the Main Proces- 
sor Phase. 


RBADJOBC -- HASPRIJC -- Subroutine to Process Illegal Job Cards 


This subroutine notifies the operator of an illegal JOB card, 
calls the subroutine: "RJOBKILL" to delete the job, and returns 
control to the Main Processor Phase. 


RJOBEND -- Subroutine to Complete Job Input Processing 


This subroutine tests whether the Input Processor is currently 
processing a job, and if it is not, returns control immediately. 
The RJOBTERM subroutine is called to terminate the input proces- 
Sing of the job, and the job is queued for the Execution Control 
Processor in the logical queue associated with the job's JOB 
CLASS. Control is then returned to the calling program. 
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RGET -- Subroutine to Get Next Card from Input Buffer 


This subroutine returns the address of the next card to be pro- 
cessed by the Input Service Processor in register "RPI". If 

the input buffer is empty or if all the cards in the input 
buffer have been processed, an IOS read is staged from the input 
device and the subroutine places the processor in a HASP SWAIT 
state until the input buffer has been filled. If the input 
device is a remote terminal, a "call" is made on the Remote 
Terminal Access Method to procure the next card. If a permanent 
error is detected on the input device, no action is taken until 
after the last card has been processed and then the JOB currently 
being processed is deleted with appropriate comments to the oper- 
ator. Processing then continues by scanning the input stream. 
for the next JOB card. 


This subroutine also processes the operator commands "SSTOP 
input device" and "SDELETE input device" by entering the HASP 
SWAIT state and calling the subroutine RJOBKILL to delete the 
job, respectively. 


There are two returns from the subroutine. If return is made 
to the first byte following the Branch and Link (the call) in- 
struction, it indicates that the last card has been processed 
and that an end-of-file has been sensed on the input device. 
If return is made to the fourth byte following the Branch and 
Link, it indicates that register "RPI" contains the address of 
the next card. 


RPUT ~- RPUTOLAY -- Subroutine to Add Card to Output Buffer 


This subroutine accepts 80-byte card images and blocks them 
into standard HASP Data Blocks (see section 8.15). If the cur- 
rent output buffer is full, it is truncated and scheduled for 
output, and a new HASP buffer is acquired and used as the next 
output buffer. If no output buffer exists upon entry, it indi- 
cates that the processor is skipping for a JOB card and the 
Subroutine returns without taking any action. 7 


RJOBKILL -- Subroutine to Delete Current Job 


This subroutine tests whether the input processor is currently 
processing a job, and if it is not, returns control immediately. 
If a job is being processed, the operator is notified that the 
job is being deleted, the RJOBTERM subroutine is called to termi- 
nate the input processing of the job, and the job is placed in 
the Print Processor Queue for subsequent processing. Control is 
then returned to the calling program. 
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RJOBTERM -- Subroutine to Terminate Job 


This subroutine terminates the last output buffer and schedules 
it for output. It then acquires a HASP buffer, and from infor- 
mation kept in the PCE Work Area (see figure 4.1.1) constructs 
the Job Control Table (JCT) and schedules it for output. Con- 
trol is then returned to the calling program. 


RGETBUF -- Subroutine to Initialize Output Buffers 


This subroutine acquires a HASP buffer for an output buffer and 
returns with the address of the buffer in register "R11". 


NON-PROCESS EXITS 


The following routines are used to put the Input Service Proces- 
sor in a HASP SWAIT state if a HASP resource is not available. 
In all cases Reader Link Register 2 ("RL2") must have been set 
to the restart address before the routine is entered. 

- RNOUNIT -- A HASP Unit was not available. 

- RNOCMB -- A HASP Console Message Buffer was not available. 


- RNOJOB -- The HASP Job Queue was full and a new entry 
could not be added. 


When the respective resource is available, the processor is 
SPOSTed and another attempt is made to acquire the resource. 
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Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT 


Displacement 


Hex. Dec. 


58 88 RDRDCT 


RCARDID Address of Input Device Control Table 





2c 92 RDADCT 
RDRSW ieee of Direct-Access DCT 
60 96 RBIEND 


Address of Last Card in Input Buffer 


64 100 RBONEXT 


Address of Next Card in Output Buffer 





68 104 RBOEND 


Address of End of Output Buffer 


6C 108 RLSAVEL 


Link Register Save Word 1 


70 112 RLSAVE2 


Link Register Save Word 2 





74 116 RLSAVE3 

Link Register Save Word 3 
78 120 RSAVEL 

General Purpose Save Word 1 
7C 124 RSAVE2 


General Purpose Save Word 2 





80 128 
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Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


Displacement 


Hex. 


80 


84 


B8 


B8 


BC 


CO 


C4 


C8 


Dec. 


128 


132 


184 


184 


188 


192 


196 


200 















RJCLTRAK 


Track Address of Next JCL Block 


RMESSAGE 


Reader Message Area 





RJOB Address of Job Queue Element 
RQUEPRI RQUETYPE RQUEJOBN Job Number 


RQUEFLAG 












Job Queue RES ERVEOD 


Flags 
RQUETRK 


Track Address of Job Control Table 








RQUEPRTR | RQUEPUNR RQUECLAS RQUEREGS 


















Print Route Punch Route Job Class Region Size 
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Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


Displacement 


Hex. 


C8 


cc 


DO 


E4 


EC 


FO 


F4 


F8 


FC 


Dec. 


200 


204 


208 


228 


236 


240 


244 


248 


252 


RJCTJOBN 


Job Number (Binary) 


RJCTJOBE 


RJCTPNAM 


RJCTJNAM 


RJCTACTN 


RJCTROOM 


RJCTETIM 


RJCTCARD 


Job Number (EBCDIC) 


Programmer's Name from Job Card 


au Ge oP aw a ao ee ow am a aD 


RJCTPRIO 


Priority 


Job Name from Job Card 


Job Accounting Number 


Programmer's Room Number 


Estimated Execution Time 


Current Input Card Count 


RJCTROUT 


Input 
Route Code 


RJCTPNAL 


Programmer's 
Name Length 





—————————————— DUMMY JOB CONTROL TABLE 
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Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


Displacement 


Hex. Dec. 


FC 252 RJCTESTL 


Estimated Lines of Output 


100 256 RJCTESTP 


Estimated Number of Cards to be Punched 


104 260 RJCTLINC RUCTCPYC RJCTLOG RJCTDDCT 


Lines | Print Log Option | EL A 
Per Page Copy Count Switch ala 


108 264 RJCTFORM 


Job Print Forms 


2a DUMMY JOB CONTROL TABLE ————————————______ > 





10C 268 
Job Punch Forms 
110 272 RJCTRDRO 
Reader Sign-On Time 
114 276 RJCTRDRT 
Track Address of First JCL Block 
118 280 RJCTCYMX 
Maximum MTTR for Current Track Group 
11C 284 RJCTMTTR 
Last MTTR Allocated 
120 288 
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Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


Displacement 


| Hex. Dec. 







120 288 RJCTCYMA 


Variable Length Track Allocation Map 


DUMMY JCT — > 


a" 


RTPCARD 


80-Byte Remote Job Entry Input Card Image Area 
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Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 
58 88 RCARDID il Type of card being processed -- 


Hex. 


Value Meaning 


00 Normal Card. 

03 Internally Generated Card. 
04 HASP Control Card. 

13 Illegal Control Card. 

19 Last JCL Card. 

73 Dummy Track Address Record. 


58 88 RDRDCT 4 Address of Reader, Tape, Internal 
Reader, or Remote Device Control Table. 


5c 92 RDRSW 1 Reader Switches -- 


Bit Name Meaning 


O RJOBQUED Job has been Queued. 
1 RSYSINSW Processing Internally Gener- 
ated DD * Card. 

2 RXBJOBSW Processing XEQ Batch Class 
Job. 

ROSINSW Processing O/S Input Data Set. 

RJCLSW Processing JCL. 

RDREOFSW End of File Indication. 

RNOSCAN Not Scanning JCL (DD DATA). 

RJFLUSH Job Flush Message has not 
been issued. 


IO WB WwW 


5C 92 RDADCT — 4 Address of Direct-Access Device Control 
Table. 

60 96 — RBIEND 4 Address of Last Card in Input Buffer. 

64 100. RBONEXT 4 Address of Next Card in Output Buffer. 

68 104 RBOEND 4 Address of End of Output Buffer. 

6c 6108 RLSAVEL 4 Link Register Save Word l. 

70 112 RLSAVE2 4 Link Register Save Word 2. 

74 116 RLSAVE3 4 Link Register Save Word 3. 
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Figure 4.].1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


Displacement Field Name 


Hex. 


78 


7C 


80 


84 


B8 


B8 


BY 


BA 


BC 


BD 


CO 


C4 


C5 


C6 


C7 


C8 


Dec. 
120 
124 
128 
132 


184 


184 


185 
186 


188 


189 
192 


196 


197 


198 
199 
200 


202 


RSAVE1 4 
RSAVE2 4 
RJCLTRAK 4 
RMESSAGE 52 
RJOB 4 
RQUEPRI 1 
Bits 0-3 
Bits 4-7 
RQUETYPE 1 
RQUEJOBN 2 
RQUEFLAG 1 
3 
RQUETRK 4 
RQUEPRTR i 
RQUEPUNR 1 
RQUECLAS 1 
RQUEREGS 1 
RUCTJOBN 2 
RJCTPRIO 1 


Bytes Field Description 


General Purpose Save Word l. 
General Purpose Save Word 2. 
Track Address of Next JCL Block. 
Reader Message Area. 


Address of Job Queue Element 
(when Job has been Queued). 


Job Queue Priority (Before Queueing) -- 


Priority (0-15). 
Zero. 


Job Class - X'80' (Before Queueing). 
Job Number (Before Queueing). 
Job Queue Flags -- 
Bits Name Meaning 
O  QUEHOLDL Job Held: TYPRUN=HOLD 
or Input Device Held. 
L-7 Reserved. 


Reserved. 


Track Address of Job Control Table. 


Print Routing: 0O Local. 


n = Remote n. 
Punch Routing: O = Local. 
n = Remote n. 


Job Class - xX'80' (After Queueing). 
Region Size -- Reserved. 
Job Number (Binary). 


Priority from /*PRIORITY Card. 
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Figure 4.1.1 -- INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


| Displacement Field Name Bytes Field Description 


Hex.. 


CB 


CC 


CF 
DO 
E4 
EC 
FO 
F4 
F8 
FC 

100 

104 


105 


106 


107 
107 
108 
10¢ 
110 
114 
118 


Lic 


Dec. 


203 


204 


207 


208 


228 


236 


240 


244 


248 


252 


256 


260 


261 


262 


263 


263 


264 


268 


272 


276 


280 


284 


RJCTROUT 


RJCT JOBE 
RJCTPNAL 
RJCTPNAM 
RJCTUNAM 
RJCTACTN 
RJCTROOM 
RJCTETIM 
RJCTCARD 
RJCTESTL 
RJCTESTP 
RJCTLINC 
RJCTCPYC 
RJCTLOG 

RJCTDDCT 
RUCTFLAG 
RJCTFORM 


RUJCTRDRO 
RUCTRDRT 
RICTCYMX 


RJCTMTTR 


1 


Local. 


Input Route Code: 0 
| Remote n. 


n 


Job Number (EBCDIC). 


Programmer's Name Length. 

Programmer's Name from Job Card. 

Job Name from Job Card. 

Job Accounting Number. 

Programmer's Room Number. 

Estimated Execution Time. 

Current Input Gard Coane. 

Estimated Lines of Output. 

Estimated Number of Cards to be Punched. 
Lines per Page. 

Number of Copies of Print. 

Log Option Switch. 

Count of Input Data Sets SPOOLed by HASP. 
JCT Flags. 

Job Print Forms. 

Job Punch Forms. 

Reader Sign-On Time. 

Track Address of First JCL Block. 
Maximum MTTR for Current Track Group. 


Last MTTR Allocated. 
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Figure 4.1.1 -~ INPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 
120 £288 RJCTCYMA Variable Length Track Allocation Map. 


RTPCARD 80 Remote Job Entry Input Card Image Area. 
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4.2 EXECUTION CONTROL PROCESSOR 


4.2.1 Execution Control Processor — General Description 


The Execution Control Processor is responsible for the interface 
between HASP and OS/360. It presents jobs ettne Operating System 
for execution and acqmunleateanwinh the I/O supervisor to supply SYSIN 
data for a job and to accept SYSPRINT and SYSPUNCH from a job for 
later printing and punching. 

This Processor is re-enterably ee and has the capability to 
present any number of jobs to OS/360 for simultaneous execution by 
maintaining unique INPUT/OUTPUT streams for each job. All storage 
unique to a job is retained in the Processor Control Element (see 
Figure 4.2.2) to provide re-enterability. 

The Execution Control Processor is also responsible for monitoring 
job limit excessions (such as time, line, or punched card estimates). 
Jobs are selected for OS processing based on a logical partition structure 
defined by HASPGEN. Each logical partition is controlled by a partition 
information table (PIT) which indicates the eligibility of jobs for 
execution by that egies partition. There is a direct correlation between 
the HASP logical partition and the number of initiators active in the 
system. Jobs thus saiiscted for OS processing are passed to a single 


OS/360 Reader/Interpreter which remains constantly STARTed to a 
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HASP pseudo device which appears as a 2540 card reader. Only the 
Job Contro] Language statements of a job are passed to the R/I. 

Input stream data sets, defined by DD* or DD DATA cards have been 
previously transcribed to a SPOOL disk by the HASP input service 
processor. The JCL for a job is dynamically modified by HASP to 

~ aSsign pseudo unit record devices to all SYSIN and SYSOUT data sets 
to permit interception by HASP. The job is interpreted by the R/I and 
is placed in the OS job queue for immediate selection by an initiator. 
At the completion of a job's execution, it is placed in the OS SYSOUT 
queue to be processed by an output writer, Because of the assignment 
| of pseudo unit record devices to all SYSOUT files, the output 

writer is required only to "print" the System Message Blocks from 

SYS] .SYSJOBOE. These SMB's are intercepted by HASP and are stored 
on the SPOOL disks as another print data set. After receiving the 

last SMB, HASP terminates the XEQ phase, queues the job for the 

HASP output processors and indicates that the iegiesl partition requires 
another job. All information concerning SYSIN and SYSOUT files 
assigned to HASP pseudo devices is kept in Data Definition Tables 
(DDT). There is a DDT for each active file of a job which indicates 
buffer addresses, file status, record count, etc. and is correlated with 


the proper file through the HASP pseudo device address. 
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4.2.2 Execution Control Processor — Program Logic 


The Execution Control Processor (XEQ) consists of the three 


following logical phases: 


PHASE 1 — Job Control eociaitietes and terminates job processing. 

PHASE 2 — Asynchronous I/O Handler — Interfaces with OS/360 
via the Input/Output Supervisor (IOS) to perform 
SYSIN/SYSPRINT/SYSPUNCH I/O requests. 

PHASE 3 — Synchronous I/O Handler — Performs the SPOOL I/O 


required by Phase 2. 


Figure 4.2.1 indicates the relationship between these three phases and 


~OS/360. 


An OS execution is initiated by Phase 1 by obtaining a suitable job 
from the HASP job queue and reading its Job Control Table from disk. Job 
limit parameters are initialized and the status of the OS/360 R/I is interro- 
gated. If the R/I is currently processing the input for another job, Phase l 
SWAITs until it has completed. A DDT describing the JCL file for the sel- 
ected job is eae mucied and associated with the HAS P pseudo 2540 used by 


the R/I. The dormant R/I is then POSTed to signal the availability of 
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a job and control is transferred to Phase 3 to await I/O requirements 
from Phase 2. The OS/360 Supervisor call table has been modified by 
HASP initialization so that all I/O requests are diverted to Phase 2 of 
the XEQ processor. If the I/O request thusly intercepted refers to a 
HASP pseudo device, it is processed by HASP; otherwise it is passed 
to the Operating System Input-Output Supervisor for normal processing. 
Since XEQ@ has the capability to control the simultaneous execution of 
many jobs, the PCE for the job issuing the I/O request to a pseudo 
device must be identifiable. This is done by using a combination of 
the JOB name and the TCB address (Job Step TCB for MVT). Once the 
PCE is located, the DDT for this particular pseudo device is found by 
the pseudo sevice address from the UCB. Phase 2 verifies that there 
is a buffer still associated with the file and simulates the I/O request. 
Each channel command word in the request is examined and, whena 
data select type is recognized, the I/O operation is simulated by a 
MOVE CHARACTERS to or from the current HASP buffer for that file. 
Input ssriseis are serviced by stripping (deblocking) the next card image 
from the HASP buffer and moving it as indicated by the CCW. These 
moves (only) are done while operating under the requesting program's 
protect key to prevent an undetected protect violation by HASP, which 


normally operates under protect key zero. Requirements for I/O 


Execution Control Processor — Page 4.2-4 


51 


HASP 


activities associated with Phase 2 processing are iagieatea by a series 
of status bits in each DDT. Requests to get Bueees:, read buffers and 
write buffers, are indicated in the appropriate DDT, Phase 3 of the 
XEQ processor is $POSTed and the HASP face is POSTed. If the re- 
quested activity must be completed before an I/O request can be 
satisfied by Phase 2, the I/C requestor is made to WAIT. this is done 
by saving the current CCW location and using the OS WAIT routine to 
hold the requestor. When the required I/O activity is complete, the 
WAITing task is POSTed and the pseudo device I/O request is re-issued. 
At the end of all successful I/O operations, the appropriate user 
appendage (channel-end appendage, etc.) is entered, the I/O is 
POSTed complete if required and a CSW is constructed to indicate the 
normal I/O completion. 

When Phase 3 of the Execution Processor is entered after initiation 
of the job it immediately enters a HASP S$ WAIT state to await direction 
from Phase 2. Upon being activated via a SPOST from Phase 2 or by 
a timer interrupt, this PHASE examines various status bits in the PCE 
and DDT's to determine the required action. This action may be either 
the priming of an input buffer, writing and re-initialization of an output 
buffer, or the astesics to the operator of expiration of the estimated 


time of the job. An input buffer is primed by obtaining the track address 
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of the next buffer from the current buffer and issuing a read for the record. 
Status bits are set in the DDT to indicate that a read is in progress on 
this buffer and are reset at channel end time to indicate that the record 
is available. A full output buffer from Phase 2 is scheduled for trans- 
cription to disk and a new buffer is immediately obtained and initialized 
for use. When the buffer is initialized a track address is acquired and 
inserted as a forward chain in the buffer to be written. If Phase 3 is 
for any reason unable to get a HASP buffer, a special service called 
Buffer-roll is invoked. The function of Buffer-roll is to make a HASP 
buffer currently being utilized by another file (in this or another job) 
available to the requestor. This is done by selecting a low frequency 
‘DDT which owns a buffer and forcing a "free" of that buffer. To free a 
primary or secondary input buffer, a switch is set in the DDT to force 
a reread of the buffer when the input file is next required. Output 
buffers are freed by terminating and writing the buffer to the SPOOL 
disk. Future references to this output file will cause a new buffer to 
be obtained and chained to the partial buffer. 

A count of the number of logical records contained in each output 
buffer is maintained by the Phase 2 routine and is used by Phase 3 
upon wteing a buffer to maintain the total line and card count for this 


job. This accumuiated figure is also compared, after each write, to 
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the estimated number of output records with che operator being notified 
on its excession. If a job exceeds sities cards, lines, or time, the 
Operator is so advised and a HASPGEN value is added to the original 
estimate which will cause repeated excession messages as this new 
estimate is reached. The job continues through normal OS/360 
processing until the end of execution is reached. The job, as part 
of normal OS job termination, fe then placed in the OS SYSOUT queue 
for processing by an output writer. Because of the dynamic modification 
of all SYSOUT= cards to pseudo devices, the Saiy data set to be 
processed by the output writer is that containing the System Message 
Blocks. The Output Writer therefore "prints" the 
SMB's to a HASP pseudo device. When the last SMB is received, Phase 
3 is notified (via an OS POST) to return control to Phase 1 for HASP job 
termination. 

The job termination section of Phase 1 must now prepare the job 
for passage to the print queue. First, all partially filled output buffers 
are truncated and written out, and all input buffers are freed. The 
timer interval for the ee cancelled and all job execution statistics 
are added to the ICT. At this point the areas of the SPOOL disks used 
to store the job input information are made available to be re-allocated 


by HASP (Purged), the JCT is written to disk and the job is passed to 
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the print queue for printing. If no priority card was present, the job 
priority is recalculated as a function of the number of lines of print 
generated before the job is placed in the print queue. 

A branch is then made to the beginning of XEQ to begin another 
job if available, or to display a message indicating that the logical 
partition is idle. 

The process of dynamic examination and modification of selected 
JCL statements is accomplished by invoking the standard OS Reader/ 
Interpreter exit list option which allows users to inspect all JCL en- 
coded by the reader. A detailed discussion of the HASP processing 


algorithm is contained in Appendix 12.8: HASP JCL Processing. 
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Figure 4.2.1 -- Execution Control - OS/360 Relationship 
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Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT 


Displacement 


Hex. 


58 


5C 


60 


64 


68 


70 


74 


78 


80 


Dec. 


88 


92 


96 


100 


104 


112 


116 


120 


128 





XPCEECB 


Job Synchronization Event Control Block Chain 


XPCEJST 


Address of User Task Control Block 


XPCEJOB 


Address of Job Queue Entry 


XPCEWAIT 


Reader Unit Allocation Event Control Block 


XPCEJOBN 


XPCEDCT 


XPCESTAT Address of Direct-Access DCT 


XPCEDDB 


Start of Data Definition Table Chain 


XPCESTEP 
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Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT (CONTINUED) 


Displacement 


Hex. Dec. 





80 128 
‘Procedure Step Name 
88 136 | XPCEPRT 
Current Output Line Count 
8C 140 
Estimated Lines of Output 
90 144 
Line Estimate Excession Amount 
94 148 
EBCDIC Constant -- "LINE" 
98 152 XPCEPUN 
Current Output Card Count 
9C 156 
Estimated Punched Cards 
AO 160 
Card Estimate Excession Amount 
A4 164 
EBCDIC Constant -- "CARD" 
AB 168 


Execution Control Processor - Page 4.2-11 


58 


HAS P 


Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT (CONTINUED) 


Displacement 


Hex. 


A8 


AC 


B8 


BC 


CO 





Dec. 
168 XPCEPIT 
Address of Partition Information Table 
172 
Execution Timer Queue Element 
184 XXSTIME 
Time Estimate Excession Amount 
188 XPCEJSIB 
Address of User JSTCB (MVT) or PIB (MFT) 
192 
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Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT (CONTINUED) 


Displacement Field Name 


Hex. Dec. 


58 


5C 


60 


64 


68 


70 


70 


74 


78 


80 


88 


8C 


90 


94 


98 


9C 


88 


92 


96 


100 


104 


112 


112 


116 


120 


128 


136 


140 


144 


148 


152 


156 


- XPCEECB 


XPCEJST 
XPCEJOB 
XPCEWAIT 
XPCEJOBN 


XPCESTAT 


XPCEDCT 
XPCEDDB 


XPCESTEP 


XPCEPRT 


XPCEPUN 


Bytes Field Description 


4 


0 


p=! 


> 


Job Synchronization Event Control Block > 
Chain. 


Address of User Task Control Block. 
Address of Job Queue Entry. 


Reader Unit Allocation Event Control Block. 


Job Name. 


Status -- 


Bit Name Meaning 


O-1 Reserved. | 

2 XPOSTBIT POST Request for XTHAW. 

3 XRDRACT #£=Reserved. 

4  XEOJMES = End Execution Message Sent. 
5 XDUPBIT Job with Duplicate Job Name 


Waiting. 
XUCBDDB UCB/DDT Required by 
~ Execution Interface. 
7 XEQJBIT #£=-End of Job Flag. 


o>) 


Address of Direct-Access DCT. 

Start of Data Definition Table Chain. 
Step Name. 

Procedure Step Name. 

Current Output Line Count. 

Estimated Lines of Output. 

Line Estimate Excession Amount. 
EBCDIC Constant -- "LINE". 

Current Output Card Count. 


Estimated Punched Cards. 
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Figure 4.2.2 -- EXECUTION CONTROL PCE WORK AREA FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 


AO 160 4 Card Estimate Excession Amount. 

A4 164 4 EBCDIC Constant -- "CARD". 

A8 168 XPCEPIT 4 Address of Partition Information Table. 

AC 172 XSTQE 12 Execution Timer Queue Element. 

BB 184 XXSTIME 4 Time Estimate Excession Amount. 

BC 188 XPCEJSIB 4 MVT -- Address of Job Step Task Control Block. 
MFT -- Address of Partition Information Block. 
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OUTPUT SERVICE PROCESSOR (PRINT AND PUNCH) 


OUTPUT SERVICE PROCESSOR - GENERAL DESCRIPTION 


The functions of the Output Service Processor are as follows: 


To convert the print and punch output generated by the 
Execution Control Processor to hard copy. 


To provide for the unique identification of both print 
and punch output to facilitate collection and delivery. 


To provide for the routing of special data sets to printers 
and punches reserved for special forms processing. 


To produce multiple copies of print output upon request. 
To count print lines and produce automatic page overflow. 


To translate all illegal print characters to blanks (option- 
al). 


To load the Universal Character Set Buffer (optional). 
To load the Forms Control Buffer (optional). 


To provide additional information for checkpoint which 
allows print to continue in the event of a "warm start". 


‘To punch a Job Accounting Card (optional). 


To process all printer and punch I/O errors with automatic 
error recovery (no operator intervention). 


To respond to all operator commands directed toward any 


printer or punch. 


To queue jobs for the next stage of processing when the 
current print/punch function has been completed. 


The Output Service Processor is coded re-enterably in such a 
way that it can deliver output to a number of different output 
devices simultaneously. The re-enterability is attained by 
retaining all storage unique to a job in the Processor Control 
Element (see figure 4.3.1) which must oh unique for each output 
device. 
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OUTPUT SERVICE PROCESSOR - PROGRAM LOGIC 


The Output Service Processor is divided into three phases, 
nine subroutines, and two non-process exits. This section 
will give a functional description of each of these phases, 
subroutines, and exits to aid the system programmer in gaining 
a working knowledge of the processor. 


PHASES 
Phase 1 -- Processor Initialization 


The Initialization Phase begins by attempting to get an out- 
put unit. If an output unit is not available, the processor 
enters a HASP SWAIT state until a device is made available 
and then the process is repeated. 


Next, an output function is determined. If the device ac- 
quired is a remote printer, the appropriate entry in the 
Remote Message Table is examined to determine if any remote 
messages have been queued, and if so processing continues. 
The general purpose register: "JCT" is set to zero to indi- 
cate that remote messages are being processed. 


If the device is not a remote printer, or if there are no 
messages queued, an attempt is made to obtain a job from the 
Job Queue which matches the type, routing and special forms 

of the device obtained. If no jobs are queued which fit these 
qualifications, the special forms processing type is checked 

to see if the forms requirement can be dropped. If so, another 
attempt is made to obtain a job from the Job Queue which 
matches the type and routing specifications only. 


If a job cannot be found, then the output unit is released 
and control is returned to the start of the Initialization 
Phase. 


If the output device is a remote terminal, output activity is 
initiated by calling upon the Remote Terminal Access Method 
(RTAM) to "open" the Remote Device Control Table. 


The processor then acquires a direct-access Device Control 
Table (DCT) and a HASP buffer into which the Job Control 

Table (JCT) is then read. A message is sent to the operator 
notifying him that a particular job is now on the respective 
device and the initialization of the Processor Control Element 


Work Area (see figure 4.3.1) is completed. 
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If the processor is processing print output, and if the output 
is not a data set which has been routed for special forms, 

the PRINTID subroutine is called to generate the print identi- 
fication header and control is transferred to Phase 2. 


If the processor is processing punch output, and if the output 
is not a data set which has been routed for special forms, 

the Punch ID Card is generated for later punching, and control 
is transferred to Phase 2. 


Phase 2 - Main Processor 


The function of the Main Processor is to read the data blocks 
which are produced by the Execution Control Processor and build 
a channel program to print or punch the data. The PRDBUF and 
PRDCHK subroutines are used to read the data blocks, the PPPUT 
subroutine is used to construct the channel program and the 
PPWRITE and PPCHECK subroutines are used to initiate and check 
the execution of the channel program. 


If the processor is processing print output, the "Control 
Byte" fields of the Data Block (see figure 8.15.1) are used 
to build the CCW operation codes. These control bytes are 
also used to count the actual lines of paper spaced and when 
this line count exceeds the parameter JCTLINCT, an eject is 
inserted to force a new page and the count is restarted. If 
an illegal control byte is encountered, or if the operator 
has entered a "ST PRTn,C=1" command, a single-space CCW is 
generated and used rather than the one provided in the data 
block. In such cases line counting continues and automatic 
page overflow is still provided. 


If the processor is processing punch output, a "Punch, Feed, 
and Select Stacker P2" command is generated. 


When the last data block has been printed or punched, control 
is transferred to Phase 3. 


Phase 3 - Processor Termination 


The Processor Termination Phase first reads the Job Control 
Table and scans the Peripheral Data Description Blocks (see 
figure 8.8.1) for the next data set to be processed. If 
another data set is encountered, control is returned to Phase 
2 for processing. If no more data sets are to be processed, 
the termination phase then proceeds depending upon the type of 
output which is being processed. 


3-3 
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If the processor is processing print output, the "Print Copy 
Count" field in the JCT (see figure 8.8.1) is compared with 

the current number of copies which have been printed. If 

more copies are needed, control is transferred to Phase 1 for 
the production of another copy. If no more copies are required, 
the PRINTID subroutine is called to generate the print identi- 
fication trailer. 


If the processor is processing punch output, the job accounting 
Subroutine is called, and the accounting card is punched fol- 
lowed by a blank card to clear the punch and check the punching 
of the Job Accounting Card. 


The Job Control Table is then re-written, the Job Queue Element 
is passed to the next processor queue, the Device Control 
Tables are released, and control is transferred to the start 

of Phase l. 


SUBROUTINES 
PLOADUCS -- Subroutine to Load the UCSB and FCB 


This subroutine determines the Universal Character Set Type 
from the Printer Device Control Table. The UCSB Table is then 
searched and the corresponding UCS image (if one is found) is 
$LOADed and moved into a HASP buffer. The UCS Buffer is then 
loaded using the PPPUT, PPWRITE, and PPCHECK subroutines. 


If the output device type specifies a 3211 printer, then the 
Forms Control Buffer is loaded in a manner similar to the UCS 
Buffer. After loading the FCB, the FCB type is reset so that 
no more FCB loads will occur until the operator specifies that 
the buffer should be re-loaded. 


PRINTID -- Subroutine to Generate Print Identification 


This subroutine builds up the line image which is used to pro- 
duce the Print Identification Page from information in the Job 
Control Table and information passed to the subroutine at the 
time it is called. This line image is built up in the "Job 
Accounting Storage" section of the Job Control Table (see fig- 
ure 8.8.1). The subroutine then builds a channel program 
which starts with an eject command and follows with enough 
print commands to completely fill a page with print identifi- 
cation lines. The channel program is then executed and checked 
and control is returned to the calling program. The PPPUT 
subroutine is used to construct the channel program, and the 

£ PPWRITE and PPCHECK subroutines are used to initiate and check 

. the execution of the channel program. 
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PPFORMCK -- Subroutine to Mount Forms 


This subroutine compares the forms being requested with the 
forms currently mounted on the associated device. If a match 
is found, the subroutine returns immediately. Otherwise, a 
forms mount message is issued to the operator and the sub- 
routine SWAITs for a "S$Sdevice" command to be entered. The 

DCT Forms field is then set to reflect the new forms type and 
processing continues. 


PRCOMENT -- Subroutine to Add Comment to Printer Output 


This subroutine constructs and adds to the printer output 
(using the PPPUT, PPWRITE, and PPCHECK subroutines) a comment 
of the form: 


PRINT xXxXxxxxxxx BY OPERATOR. 


"XXXXXXXxXxX" is specified at subroutine entry by parameter 
register "Rl" and will be one of the following: 


DELETED 
RESTARTED 
REPEATED 
BACKSPACED 
FWD-SPACED 
SUSPENDED 


PRDBUF -- Subroutine to Initiate Read from Direct Access Storage 


This subroutine initiates a read from the track address speci- 
fied by register "PNP" into the appropriate HASP buffer. 


PRDCHK -- Subroutine to Check Read from Direct Access storage 


This subroutine checks the read initiated by the PRDBUF sub- 
routine. If the read is not complete, the processor is placed 
into a HASP SWAIT state until the read is completed. If an 

I/O error is detected, a "S$IOERROR" macro-instruction is issued 
and the processing of the rest of the data set is deleted. 


This subroutine also checks for any operator command which 
would cause the Main Processing Phase to be completed and forces 


any indicated completion by zeroing the chain track in the data 
block just read. | | 
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PPPUT -- PPUTOLAY -- Subroutine to Build a Channel Program 


This subroutine accepts a CCW from the calling program and, 
1f the output device is not a remote terminal, constructs a 
Channel program in the Processor Control Element Work Area 
(see figure 4.3.1). Each command is examined and if it is an 
immediate printer space or skip, and if the previous command 
was a "Write, No Space", the two commands are combined into 
one. When the channel program storage area is full, this sub- 
routine calls the PPWRITE subroutine to initiate the execution 
of the channel program. Upon the next entry, the execution 


of the channel program is checked by calling the PPCHECK sub- 
routine. 


If the output device is a remote terminal, the Remote Terminal 
Access Method is "called" to process the output line or card. 
Control is then given to the PPCHECK subroutine to test for 
Operator commands. 


PPWRITE--Subroutine to Initiate Execution of the Channel Program 


If the output processor is being deleted by operator action, 
this subroutine returns immediately. Otherwise a write is 
initiated on the respective output device, using the channel 

program developed by the PPPUT subroutine. 


-PPCHECK-~Subroutine to Check the Execution of the Channel Program 


This subroutine checks for the successful completion of the 
Channel program execution initiated by the PPWRITE subroutine. 
If the execution has not yet completed, the subroutine enters 
the processor into a SWAIT condition until the output has 

been completed. If an unsuccessful completion is detected, 
the subroutine performs the error recovery described in the 
paragraph below. This subroutine also interprets all operator 
commands directed at the processor and initiates appropriate 
action. | 


NON-PROCESS EXITS 


The following routines are used to place the Output Service 
Processor into a HASP SWAIT state if a HASP resource is not 
available. In both cases the non-process register ("PNP") 
must have been set to the restart address before the routine 
is. entered. | 
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. PNOUNIT -- A HASP unit was not available. 
- PNOBUF -- A HASP buffer was not available. 


When the respective resource is made available, the processor 
is $POSTed and another attempt is made to acquire the resource. 


PRINTER "WARM START" LOGIC 


When the Output Service Processor is successful in acquiring a 
job from the print queue, the print checkpoint area is searched 
for an available Print Checkpoint Element (see figure 4.3.2). 
This element is thereafter used to record the job number, copy 
count, and line and page counts. 


In the event of a "warm Start", the elements are searched and 
each Print Checkpoint element is moved into the Job Control 
Table for the job which it represents. 


When the job is printed, the JCT is examined, and if the Print 
Checkpoint Element is present, the processor continues printing 
from the point when the last checkpoint was taken. 


OUTPUT PROCESSOR BUFFER LOGIC 


The buffer logic that the output processor employs is determined 
by the HASPGEN parameters: $PRTBOPT, $PUNBOPT, $RPRBOPT, and 
$RPUBOPT. 


Buffer Option = l 


One buffer will be obtained at the beginning of output proces- 
Sing and will be used through the entire processing of a job's 
output. A read for the following data block will not be ini- 
tiated until the current data block has completed its output. 
Periods of high Input/Output activity could cause the printers 
and punches to operate at less than their maximum rate when 
this option is used. 


Buffer Option = 2 


Two buffers will be obtained at the beginning of output pro- 
cessing and will be used through the entire processing of a 
job's output. A read for the following data block will be 
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initiated as soon as the previous data block has completed 
its output and will be performed while the current data block 
is completing its output. This option represents the most 
efficient utilization of the output devices. 


PRINT AND PUNCH ERROR RECOVERY 


Print Errors 


The operator will be informed of all printer errors, but they 
will be ignored by the Output Service Processor. 


Punch Errors 


The card which causes a punch check and the card following 
this card are selected automatically into the reject stacker. 
The Output Service Processor will attempt to punch these two 
cards correctly until no error occurs or the operator deletes 
the job. Since all normal punch output is selected to another 
stacker, no operator intervention will be required to clear 
the punch. Every error will be recorded on the operator's 
console. 
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Figure 4.3.1 -- OUTPUT SERVICE PCE WORK AREA FORMAT 


Displacement | 


Hex. 


58 


SC 


60 


64 


68 


6C 


70 


74 


78 


8c 


Dec. 


88 


92 


96 


100 


104 


108 


112 


116 


120 


140 











Address of Print/Punch/Remote DCT 







PPFLAG 


PDADCT 


PDCTFLAG 





Address of Direct-Access DCT 












Address of Job Queue Entry 


PRG ae Address of Print Checkpoint Element 


PUERRPT | Address of Punch Error CCW 


PTIMEON 


Print/Punch Sign-On Time 


PBUFSAVE 


Address of Next Print/Punch Buffer 


PCCWPT 


Address of Last Print/Punch CCW Set Up 


PCCWEND 
Address of Last Possible Print/Punch CCW 





PMESSAGE 


Print/Punch Message Area 
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Figure 4.3.1 -- 


Displacement 


Dec. 


Hex. 


8C 


90 


94 


98 


9C 


AO 


A4 


A8 


140 


144 


148 


152 


156 


160 


164 


168 


PDDBSKI 


Count o 


PDDBDIS 


Current 


PPLNCDC 


PRPAGEC 





PDEVTYP 


PRLINEC 


PCCWCHN 


OUTPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


P PPRCFLAG PPRCPYCT 


f Pages to Skip Checkpoint Copy Count 
Flags 


P PDDBPGCT 
PDDB Displacement Current PDDB Page Count 
T 

Current Line or Card Count 


T 


Current Page Count 


E 


PBUFOPT Print/Punch Device Type 


PLSAVE 


Link Register Save Word 









T 


Maximum Lines per Page 


Variable Length Print/Punch CCW Chain 
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Figure 4.3.1 -- OUTPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


Displacement 


Hex. 


58 


58 


5C 


5c 


60 


64 


64. 


68 


6C 


Dec. 


88 


88 


92 


92 


96 


100 


100 


104 


108 


PPFLAG 


PDCT 


PDCTFLAG 


PDADCT 


PJOB 


PRCHKPTE 


PUERRPT 
PTIMEON 


PBUFSAVE 


Field Name Bytes Field Description 


Print/Punch Synchronization Flags -- 


Bit Name Meaning 


O  PPWSW Write has been Initiated. © 
il PPDELSW Function has been Deleted. 
2 PPNOJOB No Job is Active. 
3 PRDELSW # Print was Deleted by 
Operator. 
4 PRRSTSW- Print was Restarted by 
| Operator. 


5 PPRDERR Function Terminated by 
Read Error. 
6-7 Reserved for Future Use. 


Address of Print/Punch/Remote 
Device Control Table. 


Print/Punch/Remote Operator Commands -- 


Bit Name Meaning 


O DCTSTOP $Z (SSTOP) Command. 

1 DCTDELET $c (SDELETE) Command. 

2 DCTRSTRT SE (SRESTART) Command. 

3. DCTRPT SN (SREPEAT) Command. 

4 MDCTBKSP $B (SBACKSPACE) Command. 
5  DCTSPACE S$T...,C=1 Command. 
2+4 $I Command. 
6-7 Reserved. 


Address of Direct-Access Device Control 
Table. 


Address of Job Queue Entry. 


Print Only: Address of Print Checkpoint 


Element. 


Punch Only: Address of Punch Error CCW. 


‘Print/Punch Sign-On Time. 


Address of Next Print/Punch Buffer. 
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Figure 4.3.1 -- OUTPUT SERVICE PCE WORK AREA FORMAT (CONTINUED) 


Displacement Field Name 


Hex. 


70 
74 
78 
8C 


8E 


8F 
90 
92 
94 
98 


9C 


9C 
AO 
A4 


A8 


Dec. 


112 


116 


120 


140 


142 


143 


144 


146 


148 


152 


156 


156 


160 


164 


168 


PCCWPT 
PCCWEND 
PMESSAGE 
PDDBSKIP 


PPRCFLAG 


PPRCPYCT 


PDDBDI SP 


PDDBPGCT 


PPLNCDCT. 


PRPAGECT 


PBUFOPT 


PDEVTYPE 
PLSAVE 
PRLINECT 


PCCWCHN 


Bytes Field Description 


4 


4 


20 


Address of Last Print/Punch CCW Set Up. 
Address of Last Possible Print/Punch CCW. 
Print/Punch Message Area. 

Count of Pages to Skip. 


Checkpoint Flags -- 


Meaning 


Bit Name 

O PRCHKUSE Checkpoint Element Assigned. 
1 PRCHKJOB Job Active Indication. 

2-7 Reserved. 


Current Copy Count. 

Current PDDB Displacement. 
Sueeenk PDDB Page Count. 
Current Line or Card Count. 
Current Page Count. 


Buffering Option -- 


Value Meaning 
1 Single Buffering. 


2 Double Buffering. 
Device Type from UCB (UCBTYP) . 
Link Register Save Word. 
Maximum Lines per Page. 


Variable Length Print/Punch CCW Chain. 
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Figure 4.3.2 -- PRINT CHECKPOINT ELEMENT FORMAT 


Hex. Dec. 


Displacement - 


0 0 PRCJOBNO PRCFLAGS PRCCPYCT 


Checkpoint Job Number Checkpoint Checkpoint 
. Flags Copy Count 


4 4 PRCPDDBD PRCPDDBP 


Checkpoint PDDB Displacement Checkpoint PDDB Page Count 


8 8 PRLINCT 


. Checkpoint Total Line Count 


C 12 PRPAGCT 


Checkpoint Total Page Count 





10 16 
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Figure 4.3.2 -- PRINT CHECKPOINT ELEMENT FORMAT (CONTINUED) 


Displacement 


Hex. 


0 


2 


Dec. 
@) 


2 


12 


Field Name 


PRCJOBNO 


PRCFLAGS 


PRCCPYCT 
PRCPDDBD 
PRCPDDBP 
PRLINCT 


PRPAGCT 


Bytes Field Description 


2 Job Number. 
1 Checkpoint Flags -- 
Bit Name Meaning 
0 PRCHKUSE checipeiae Element in Use. 
1 PRCHKJOB Job Active Indication. 


2-7 Reserved for Future Use. 


1 Current Copy Count. 


2 Current PDDB Displacement. 
2 Current PDDB Page Count. 
4 Total Line Count. 


4 Total Page Count. 
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PURGE PROCESSOR 
PURGE PROCESSOR - GENERAL DESCRIPTION 


The Purge processor frees the job's acquired HASP direct-access 
space and removes the Job Queue Element from the system. 


PURGE PROCESSOR - PROGRAM LOGIC 


The processor first acquires a Job Queue Element and issues the 
SACTIVE macro to inform the HASP Dispatcher that the processor 
is active. Then a direct-access Device Control Table (DCT) and 
a HASP buffer are acquired and initialized so that the job's 
Job Control Table (JCT) may be read into the buffer from the 
SPOOL disk. If a DCT or buffer is not available this processor 
will be placed in a HASP SWAIT state until a DCT or buffer can 
be acquired. If no permanent I/O errors occur while reading 
the JCT, a SPURGE macro instruction is then issued to return 
the job's direct access tracks. If a permanent I/O error occurs 
while the JCT is being read, the DISASTROUS error routine is 
called and the $PURGE macro instruction is not executed. Next, 
the Job Queue Element is removed from the HASP Job Queue and 
the following message is issued to the operator: 


JOB xxx IS PURGED 
Finally, the buffer and DCT are freed, and the SDORMANT macro 
instruction is issued to indicate to the HASP Dispatcher that 


the processor is inactive and control is returned to the start 
of the routine for the processing of the next job to be purged. 
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4.5 HASP COMMAND PROCESSOR 


4.5.1 HASP Command Processor - General Description 


The HASP Command Processor receives all HASP commands entered 

from acceptable local or remote HASP input sources. The Processor 
is responsible for decoding each command and performing the pro- 
cessing necessary to cause appropriate action to the operator's 
request. | . 


4.5.2 HASP Command Processor - Program Logic 


The HASP Command Processor is initially entered at the beginning 
of the Control Section (CSECT) HASPCOMM which is a part of the 
resident portion of HASP. Subsequent re-entries are returns from 
the various command sub-processors with optional requests for the 
displaying of the "OK" message or other message contained in the 
COMMAND area of the PCE. After displaying any requested replies 
the HASP Console Message Buffer queue $COMMQUE is examined for 
the presence of the next command to process. If no buffer is 
queued, the Command Processor waits on WORK. When SPOSTed or if 
a buffer is present upon entry, the Command Edit Routine is 
entered via SLINK macro. 


Command Edit Routine - HASPCOME 


VERB CONVERSION - The Command Edit Routine converts the command 
text from the long form to the standard single character verb form. 
The data portion of the Console Message Buffer up to the first 
comma (,) or apostrophe (') is made upper case and non-blank 
Characters are shifted to the left. The resulting text is compared 
against arguments in the VERB CONVERSION TABLE. If a match is 
found, the corresponding standard form of the command is substituted. 


COMMAND EDIT AND BREAK OUT - The information in the HASP Console 
Message Buffer is moved to the COMMAND field in the PCE work area. 
The two bytes CMBFLAGS and CMBCONS of the buffer are moved to the 
COMFLAGS and COMROUTE fields of the PCE workarea. These two 
bytes when combined with the two succeeding bytes in the PCE form 
the list form of the $WTO used for all responses to the operator 
from the Command Processor. 


The COMMAND area of the PCE is primed with blanks and the buffer 
is scanned. Solid characters are ORed (moved with upper casing) 
into the COMMAND area. Blanks encountered in the buffer will 
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normally be skipped (blank elimination); however, if an apostrophe 
is encountered, blanks will not be skipped until the next apos- 
trophe. Double apostrophe characters will cause the blank com- 
pression status to remain as previously set; however, the second 
apostrophe of the pair will be eliminated. 


As each comma is encountered an entry of the next available | 
character position is made in the COMPNTER area of the PCE. (The 
first entry is the address of the character after the verb. The 
second is the address of the second operand, etc.) When the 
COMPNTER area is full, recording is discontinued. Upon completion 
of the scan, the buffer is released, the COMNULOP field in the 

PCE is set to the address of the second character beyond the last 
solid character (null operand), and the operand pointers are 
shifted down adjacent to the COMMULOP field (see Figures 4.5.1 


to 4.5.3). Control registers are set as follows: 
WD = address of the first operand pointer in the COMPNTER field 
WE = 4 
WF = address of the last operand pointer in the COMPNTER field 


SELECTING THE COMMAND SUB-PROCESSOR - The SELECTION TABLE is used 
to determine the appropriate command sub-processor which must be 
entered. Starting with the first element, the SELECTION TABLE is 
scanned for a matching verb. When the verb is located, the first 
character of the first operand is then used for comparing. If a 
match is found on the operand or if the table entry contains an 
X'FF' for operand argument, the table entry for the command is 
considered "located". If the end of the entries is encountered 
for the verb or table, the command is considered invalid and the 
edit routine returns to the main processor with INVALID COMMAND 
message in the COMMAND area for display. (See SCOMTAB macro in 
Section 4.5.4 for format of the SELECTION TABLE element.) 


VALIDATING THE SOURCE AND ENTERING THE SUB-PROCESSOR - Each entry 
of the SELECTION TABLE may have restriction indicators as follows: 


COMRMT = 1 - Reject remote sources _ | 

COMS = 1 - Reject consoles which are restricted from 
entering SYSTEM COMMANDS 

COMD = 1] - Reject consoles which are restricted from 
entering DEVICE COMMANDS 

COMI = 1 - Reject consoles which are restricted from 


entering JOB COMMANDS 


The restriction indicators correspond with the restriction indi- 
cators which appear in the COMFLAGS field. The COMFLAGS indicator 
is previously set from the CMBFLAGS field of the HASP Console 
Message Buffer which in turn is set by other HASP processors as 
follows: 


1. CMBFLAGS when set by the remote console processor or 
remote reader processors will contain the remote 
indicator. This indicator corresponds to COMRMT bit 
in the SELECTION TABLE. 
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2s CMBFLAGS when set by the local console support routines 
will contain the restriction flags assigned to the 
Console Device Control Table. (Restriction is the 
opposite of authority which is set by the operator 
command S$TCONn,A=authority or by the system programmer.) 
3. CMBFLAGS when set by the OS console interface is 
the OS authority indicators inverted with the 
Exclusive Or Immediate (XI) instruction. 


The restriction indicators are used as the second operand of a 
Test Under Mask (TM) instruction. If any restriction indicator 
in the COMFLAGS field corresponds to any restriction indicator 

in the SELECTION table entry, the command is rejected as invalid. 
Otherwise Register 1 is set with the value in the SELECTION TABLE 
entry COMTOFF field and control is passed to the CSECT indicated 
by the Overlay Constant (SOCON) field of the SELECTION TABLE 
element via the $XCTL macro. 


Command Sub-Processor Control Sections 


The Entry routine of each command sub-processor control section 
will, if applicable, use the offset value in register 1 (set by 
the edit routine) to determine the "relative" entry point for the 
designated sub-processor. Normally the sub-processor is entered 
directly by the special Command Processor macro: "Branch 

Relative Register" on Rl ($BRR Rl). However, some control section 
entry routines will pre-process the operands of the command prior 
to entering the sub-processor. Each sub-processor performs the 
desired functions and returns to the main command processor for 
the next command. | 
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4.5.3 HASP Command Processor Organization 


The HASP Command Processor is created by a single assembly with 
multiple Control Sections (CSECT). The main CSECT HASPCOMM is 
the only portion of the Command Processor that is part of the 
HASP resident load module. It contains all V type address 
constants required by the sub-command processors and all "BASE2" 
service routines. The Command Edit Routine HASPCOME receives 
control from the main processor and determines which COMMAND 
SUB-PROCESSOR CSECT to enter for processing of the command entered. 
One or more of the various COMMAND SUB-PROCESSOR CSECTs are used > 
in processing each HASP operator command. Although the physical 
CSECTs are organized in accordance with the size of the overlay 
work area , the logical organizational grouping is as follows: 


JOB QUEUE COMMANDS 

JOB LIST COMMANDS 
MISCELLANEOUS JOB COMMANDS 
DEVICE LIST COMMANDS 

SYSTEM COMMANDS | 
MISCELLANEOUS DISPLAY COMMANDS 
REMOTE JOB ENTRY COMMANDS 


HASP Command Processor Workarea 


The HASP Command Processor PCE workarea shown in Figure 4.5.1 is 
the primary workarea for the processor and is the only area which 
may be used to save information in the event a SWAIT is issued by 
the processor or any of the "BASE1" service routines on behalf of 
the processor. The fields are generally used as described in the 
following paragraphs. 


COMFLAGS to COMCLASS - This field contains a list form of the SWTO 
macro. The SWTO is referred to by a single execute form of the 
SWTO located within the resident portion of the Command Processor 
which is used for all operator messages generated by any routine 
within the processor. The CMBFLAGS and CMBCONS fields of the HASP 
Console Message Buffer for each command is inserted into the 
COMFLAGS and COMROUTE cells and are used to provide correct route 
codes for replies. The three low order bits of COMFLAGS are 
restriction indicators and are set to zero prior to each SWTO reply. 


COMEWORK - This field is used as a workarea and by function routines 
identified by the macro instructions as follows: 
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macro contents upon exit from routine 

SCFCVE last character is blank 

SCFDCTL first four characters of requested device name 
SCFJDCT address of HASP job queue element for requested job 
SCFJIMSG same as SCFCVE 


COMDWORK - This field is aligned on a double word boundary and is 


used as a workarea and by function routines identified by the macro 
instructions as follows: 


macro contents upon exit from routine 

SCFCVE five character number in EBCDIC with leading blanks 
SCFDCTL last four characters of requested device name 
SCFJIMSG same as SCFCVE 


COMMAND - This field contains the compressed form of the operator 
command with trailing blanks at the time each command sub-processor 
is entered. The command is overlayed by the reply message text for 
all SWTO messages issued by any Command Processor routine. Some 
command sub-processors use the area as scratch areas and in some 
cases the right end for storage of critical information while 
message replies are generated in the left end of the area. 


COMPNTER-COMNULOP - These fields are set by the Command Edit 
Routine and are used to locate the beginning of each of the 
specified operands in the command currently being processed. 
COMNULOP contains a pointer to the second character beyond the 
last operand specified, i.e., points to a non-existant or "null" 
Operand. Operand 1 through n pointers are right adjusted in 
COMPNTER so that operand n pointer is adjacent to the "null" 
pointer (see Figures 4.5.2 and 4.5.3 for illustrations). Command 
sub~processors use these areas for additional workspace after the 
operand pointers are no longer needed. Examples of other uses 
are listed as follows: 


ie Job queue command SDN and $DQ commands place queue 
scanning control elements in the COMPNTER area. 

ve Job list commands place the job range numbers (j-jj) 
in the corresponding operand pointer element area. 

3. SDR uses the right end of the COMMAND area and 


COMPNTER-COMNULOP area to hold the reply ID numbers. 
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Figure 4.5.1 -- HASP COMMAND PCE WORK AREA FORMAT 


Hex. Dec. 


Displacement i 


































58 88  -COMFLAGS COMROUTE COMLNGTH | COMCLASS 
5C «92 COMEWORK | | | 
Function Work Area 
60 96 COMDWORK 
Function Work Area 
68 104 COMMAND COMVERB COMOPRND 
Message Area Command Verb | First Operand 
Command Text and Message Area 
E0 224 COMPNTER 
Address of n-4 Operand 
E4 228 
Address of n-3 Operand 
E8 232 
Address of n-2 Operand 
EC 236 
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Figure 4.5.1 -- HASP COMMAND PCE WORK AREA FORMAT (CONTINUED) 


Displacement 


Hex. 


EC 


FO 


F4 


F8 


Dec. 


236 


240 


244 


248 


COMNULOP 


Address of n-1l Operand 


Address of n Operand 


Address of n+l Operand 
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Figure 4.5.2 COMMAND - COMNULOP Areas With Single Operand Command 


COMMAND - $PPRT1bb 


COMPNTER - - - - not used Upon exit of Edit Routine, 
| , Registers WD, WE and WF | 
not used | are set for testing 
Pot instructions: 
not used BXLE WD,WE, loop 
| (for next operand) 
not used BXH WD,WE,exit 


WD, WF > | operand LH (if = more ) 


COMNULOP - - - -| null 





Figure 4.5.3 COMPNTER -COMNULOP Areas With Five Operand Commands 


COMMAND - $PPRT1,PRT2,PUN1,RDR1,RD2bb 


COMPNTER - WD + | operand lt 
operand 2+}-———! 
operand 3 


operand 4t 





WF > operand 5+ 


COMNULOP - - - - null 


NOTE: b = blank character - Upon exit of Edit Routine, 
| Registers WD,WE and WF. 
are set for testing 
instructions: 


BXLE WD,WE, loop 

(for next operand) 
BXH WD,WE,exit 

(if no more) 
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Coding Conventions 


The symbols with the command processor conform to the following 
conventions: 


Ls 


2. 


5: 


All main processor, Edit Routine, and PCE workarea symbols 
start with the characters "COM". 


All Function macro generated symbols start with "COF". 


All command sub-processors have entry point symbols 
of the following form: 


form example command comments 
Cvo CDN SDN v = the verb of the command 

o = the first operand character 
Cv CB $B device single character identifier 
Cvxx CD7D $D'jobname' apostrophe is hexadecimal 7D 





All symbols created for the support of the command will start 
with characters which identify the entry point (CDNxxxxx 
identifies a location which was originally written for the 
SDN command). Commands with no unique operand character 
symbol have the character "x" as the third character. 


WCB X cs were identifies a location which was originally written 


for the $B device command.) These conventions may be altered 
in cases where the command identification characters are 
redefined after original development. 


The main processor CSECT is HASPCOMM, all other CSECTs are 
defined via the symbol field of the SCOMGRUP macro; specified 
Starting with the characters "HASPC". 
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Register Conventions 


The Command Edit Routine passes control to the control section 
(CSECT) which contains the appropriate command sub-processor. 
At the point the Command group entry routine receives control, 
the registers will contain the following: 7 


reg contents 

RO unpredictable _ 

Rl | entry offset from the Command entry offset 
WA unpredictable 

WB unpredictable 

WC unpredictable 

WD first operand pointer (zero if no operand) 
WE 4 

WF last operand pointer 

BASE3 base for CSECT 

BASE1 HCTDSECT address 

BASE2 beginning of main Command Processor 

SAVE PCE address 

LINK unpredictable 

R15 unpredictable 


If more than one command appears within the group, the value of 
register Rl will be set by the SCOMGRUP entry routine to a value 
so that a SBRR R1 will enter the command sub-processor. 
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4.5.4 HASP COMMAND PROCESSOR MACROS 


To facilitate flexibility in the development and possible modi- 
fication of the Command Processor a macro package is included 
within the assembly source deck. This section is intended to 
Supplement the HASP Command Processor Source listings obtainable 
from the HASP generation and assembly process in assisting the user 
to understand the generated code as specifically used in the 
current HASP as distributed. 


Each HASP Command Processor macro may be dependent upon the 
definitions contained within the Command Processor source deck as 


well as other members of the HASP source library. These macros 
are catagorized as follows: 


ORGANIZATIONAL - Macros which provide basic definitions and 
are closely associated with the organization 
of the processor. 


BASE2 SERVICES - Macros which call upon the main Command 
Processor to perform a service (display a 
reply). 


CONDITIONAL IN-LINE FUNCTIONS - Macros which perform the function 
in-line or links to a routine which performs 
the desired function. 

RELOCATABILITY AIDS - Macros which assist in keeping the overlay 
CSECT relocatable around SWAIT or implied 
SWAIT situations. 


The macros which are supplied under each category are summarized 


in Table 4.5.4. The following conventions are used in specifying 
parameter requirements: : 


"parameter=** —-" - keyword parameter is required 

“parameter=text -" - the assumed value if the keyword parameter 
is not specified 

“parameter -" - the parameter is an optional positional 
parameter 

“parameter - Required" - the parameter is a required positional 
parameter. 
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Table 4.5.4 Command Processor Macro Summary. 
Op-Code Definition 
ORGANIZATIONAL; | | 
- $COMWORK COMMAND PROCESSOR WORKAREA (symbolic definitions) 
$SCOMGRUP DEFINE GROUP OF COMMAND SUB-PROCESSORS 
SCOMTAB 


BASE2 SERVICES: 
SCRET 
SCWTO 


CONDITIONAL IN-LINE 
SCFCVB 
SCFCVE 
SCFDCTD 
SCFDCTL 
SCFINVC | 
SCFINVO 
SCFJDCT 
SCFJMSG 
SCFJISCAN 
SCFSEL 
SCFVQE 


RELOCATIBILITY AIDS: 
SARR | 

SBRR 

SSRR 


DEFINE COMMAND TABLE ELEMENT 


RETURN TO MAIN COMMAND PROCESSOR 
WRITE TO OPERATOR 


FUNCTIONS : 

CONVERT TO BINARY 

CONVERT TO EBCDIC 

DEVICE CONTROL TABLE DISPLAY 
DEVICE CONTROL TABLE LOCATE 
REPLY INVALID COMMAND 

REPLY INVALID OPERAND | 
FIND JOB'S DEVICE CONTROL TABLE 
DISPLAY JOB INFORMATION MESSAGE 
SCAN JOB QUEUE ASSISTANCE | 
SELECT A ROUTINE BASED ON CHARACTER 
VERIFY CONSOLE CONTROL OVER JOB 


ADD RELATIVE REGISTER 
BRANCH RELATIVE REGISTER 
SUBTRACT RELATIVE REGISTER 


HASP Command Processor - Page 4.5-12 


88 


HAS P 
Organizational Macros 


$COMWORK - COMMAND PROCESSOR WORKAREA (symbolic definitions) 
This macro adds to the PCEDSECT definitions for 
fields located in the Command Processor PCE workarea. 
Additional symbolic constants for BASE2 services 


and some externally defined parameters are defined. 


$COMGRUP - DEFINE GROUP OF COMMAND SUB-PROCESSORS 

This macro defines the Command Processor overlay 
control section via the SOVERLAY macro. It provides 
an optional entry point routine which locates the 
command sub-processor for the commands which belong 
to the group and sets register Rl to the relative 
address. (The symbol field must be specified for 
this macro.) 


n positionals - Each positional specifies the command 
identification characters for the corresponding 
command sub-processor located within the group. 
Example: 


Specification command sub-processor entry point name 
AA SAA | 


CAA 
DA SDA CDA 
B $B device CB 
C SC device CC 
P40 $P CP40 
S40 $s CS40 
D7D $D'jobname' CD7D 


PRTY=** - Priority of the HASP overlay defined by 
the macro. : 


DELAY=NO - The sub-processor will be entered via 
SBRR Rl macro instruction. If "YES" is specified 

Rl will contain the appropriate relative entry point 
address and control will be given to the statement 
following the macro statement. (More than one posi- 
tional must be specified if Rl is to be set or the 
branch is to be executed.) 
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SCOMTAB 


- DEFINE COMMAND TABLE ELEMENT 
This macro defines an element in the command 


SELECTION TABLE which is used by the Command Edit 
Routine for identifying legal commands, eliminating 
unauthorized input sources, and entering the correct 
command group CSECT. | 3 


verb - Required - The command identification 
character(s) corresponding to the $COMGRUP positional 
parameter specification for the command. No two 
SCOMTAB macro statements may specify the same iden- 
tification character string. All macro statements 
creating entries for the same command verb will 
appear in consecutive statements with the statement 
which specifies a single identification character 
last. 





roup - Required - The exact characters used in the © 
specification in the symbol field of the appropriate 
SCOMGRUP macro statement. 


REJECT= - The command source rejection mask. One or 
more of the following symbols may be specified as 
follows: 


"COMRMT" - reject command if entered from a 
remote 
"COMS" - reject command if entered from a 
| console not authorized for SYSTEM 
control 
"COMD" - reject command if entered from a 
7 console not authorized for DEVICE 
| control 
"COMI" - reject command if entered from a 
console not authorized for JOB 
control | 


Rejection of either a remote or a console not 
authorized for SYSTEM appears as follows: 
"REJECT=COMRMT+COMS" 
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Figure 4.5.5 - Selection Table Element 


(variable) COMTOFF | COMTFL | COMTVB 


overlay constant identifiers 





COMTOFF = Offset for the overlay control section to 
locate the command sub-processor entry point. 

COMTFL = Rejection flags. 

COMTVB = Command identification characters. Verb with: 
i First character of the first operand. 
ae X' FF! 


If X'FF' is specified all commands which 
have not been specified by the previous 

entries in the table will be considered 

"selected". 
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BASE2 Services 


SCRET - 


SCWTO - 


RETURN TO MAIN COMMAND PROCESSOR 


MSG= - "Address" of the message to be moved to 
COMMAND area for display. (L=operand of a 
non-register form is required.) "MSG=OK" indi- 
cates that the main processor is to display the 
OK message. | 


L= - "Value" representing the length of the message 
that is to be moved or has already been moved. 


WRITE TO OPERATOR | 
REGISTERS USED: RO, Rl, WA, LINK, RL5 


MSG= - "Address" of the message to be moved to 
COMMAND area and displayed. (L=operand of a non- 
register form is required.) 


L=** - "Value" representing the length of the mes- 


sage that is to be moved or has already been moved. 
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Conditional In-Line Functions 


The HASP Command Processor as distributed provides for the 
ability of the author of the command sub-processor to specify 
whether or not the code which performs the function is in-line or 
out of line. If an out of line routine is used the name and 
location of the subroutine must be defined. This is accomplished 
with parameters standard for all function macro instructions 

with the exception of SCFJSCAN as follows: 


TYPE=CALL - The macro statement is not a definition form of 


the macro. "TYPE=DEF", the macro statement defines the 
Subroutine form of the function and return linkage must be 
provided. 


SYMBOL=address - The address of the "TYPE=DEF" version of 
the macro instruction. This indicates that only linkage 
to the "TYPE=DEF" version is to be provided. If neither 
“TYPE=DEF" or "SYMBOL=" parameters are specified the code 
will be generated in-line with no return linkage. 


$CFCVB - CONVERT TO BINARY 

This macro converts the numeric portion of a 

command operand to one or two numeric values. 

REGISTERS USED: RO, Rl, LINK, RL5 

RO - contains the last number converted. 

Rl - contains the next to last number converted 
(last number if the only one or the last is 
smaller than the previous). 


POINTER=(R1) - The address of the COMPNTR field 
which addresses the operand containing one or more 
numerical values separated by dash (-). 


NUM=2 - return two values. "NUM=1", one value 1s 
sufficient (Rl will be unpredictable on return). 


NOK=** - Address of the error exit routine if the 
operand does not contain a number or if the number 
is too large. 


SCFCVE - CONVERT TO EBCDIC 
This macro converts the number in register (RO) to 
printable EBCDIC and sets the five resulting digits 
in the first five characters of the PCE area 
COMDWORK. 
REGISTERS USED: RO, LINK 


VALUE=(RO) - The positive binary half-word value 
to convert to EBCDIC. If the register form is not 


used, the value is contained within the addressed — 
wade —word: 
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S$CFDCTD 


SCFDCPL ioecnoms 
seoiso. Mis macre, converts the abbreviated. ‘form of the™ 


SCFINVC 


yu be ait ts 

“hy? sae NaS 
S C F N O pe enya s me. 
| V pra: Banga) eh ak hs 
tN taal Sh eo 


SDFJDCT — 





iF. 2 DOTS (RL) The . ‘address of the Der td, aisplay. 





y 


eis INVALID ‘COMMAND - 


REPEA: INVALLD. OPERAND 


DEVICE CONTROL TABLE DISPLAY... we? aS ee 
This macro displays the ‘device. name, - Sanit ‘address °° 
and status of the DCT requested. 


“SREGESTERS, ; BSED GS Roe _ R1,. 2A. INK,. R15_. 






DEV LOR CONTHOL ‘TABLE. LOCATE. 





device name to the long .form. (if. abbreviated ea 
is specified) and searches the DCT chain fora 6 


of mosimatehing device. + eoy¢.-- 
— oo SREGISTERS.-USED:.....RO, ‘RI, “RIS, “LINK ~ 





Ri i contains. the. address. ot the. Det found | Or zero 
if no DCT found. 





vos ¥ovPOINTER:=(R1)--7 The.address of the COMPNTER | mela 
which. addresses. the. ooRerang. ‘containing: ‘the device 
‘name. (abbreviated) . 





This macro returns to fhe rer Command: ‘Processor and 
causes the Stereo "ERVALTD,, SOMMANRS 


Baye 
i aS 





This: macro moves BAD ag ss ay ‘starting with 


oothe: first. character of. the. “current”, operand to 


“FIND JOB" s DEVICE, CONTROL TABLE 


the: COMMAND area., and. returns. to. the, Main Command 


ony BEBORSOrT eausing: the. Gap ley - of "operand INVALID 


OPERAND".. 


cra aS, 7 ; ee Paraee > 
ie at aia og ad 


Ss OPERANDS ARI). 7 The address: ef, bhe, Hn RRPrans to display. 





yet 


toa job queue ae beiseaite. to “the ooo eo Jee 


oo scoLf -the device .ds. not found. exit. will. be to the 
instruction immediately. following: the SCFJDCT state- 


ment (in-line code version); otherwise, exit will be 


“on a4 


to the instruction plus 4 “(NSI+4). 
REGISTERS USED: R1, LINK, R15........ 


5... JOBQE=(R1). - “The. address. of ‘the HASP ace queue 
ote, ~osenbtry -for..- ‘the. desired job. 
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SCFJMSG 


SCFJSCAN 


- DISPLAY JOB INFORMATION MESSAGE 


This macro sets into the COMMAND area of the PCE 
the information required for the JOB INFORMATION 
MESSAGE and displays the message. 

REGISTERS USED: RO, Rl, WA, LINK, RIL5 


JOBQE=(R1) - The address of the HASP job queue 
entry for the desired job. 


JDCT= - The address of the $CFJDCT TYPE=DEF macro 
which may be used to locate the job's DCT. Register 
form is prohibited. 


CVE= - The address of the $CFCVE TYPE=DEF macro 
which may be used to convert numeric information 
to EBCDIC. Register form is prohibited. 





JOB= - This parameter may be ignored by the macro; 
however, if specified as "JOB=SET" the text "JOBjJ" 
is assumed by the expanded routine to have been set 
in the COMMAND area for the desired job. 


OPT= - This parameter may be ignored by the macro; 
however, if specified as "JOB=Q" all jobs given to 
the macro expansion are queued (not active) or 

if specified as "JOB=A" all jobs given to the 
expansion are active. 





SCAN JOB QUEUE ASSISTANCE 


This macro is used to assist in scanning the job 
queue. As each entry is located the user's PROCESS 
routine is entered. The user examines the entry, 
performs whatever function desired on the entry, 
and returns to the symbol specified by the "NEXT=" 
operand. When the end of the queue is encountered, 
control is given to the instruction following the 
macro instruction. An optional feature of the macro 
is to allow the PROCESS routine an "IGNORE' entry 
to the generated code to indicate the current job 
entry is not acceptable to the PROCESS routine. If 
the "IGNORE=" option is specified the corresponding 
"EMPTY=", option is required. Register 1 is the 
scan register and 1S assumed to be unaltered by the 
user PROCESS routine. The "TYPE=DEF" option is not 
permitted for this macro. 

REGISTERS USED: Rl, BASE2 

Rl - scan register 

BASE2 - found/not found switch (in addition to 
processor base. 
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SCFSEL 


SCFVQE 


PROCESS=** - Address of the user's job queuve element 
processing routine. Register form prohibited. 


IGNORE= ~ Symbol to be used to define the entry to 
continue scan when the current job entry is not 
of the desired type. 


NEXT=** - The symbol to be used to define the entry 
to continue scan when the current job entry is 
of the desired type. 


EMPTY= - The name of the user exit routine desired 
to be entered when the job queue is found to be 
empty of jobs of the desired type. Register form is © 


prohibited. 


SELECT A ROUTINE BASED ON CHARACTER 

This macro matches the designated input character 
against a list of arguments and transfers control to 
the routine designated by the corresponding address. 
If no match is found, the next sequential instruction 
is entered. 

REGISTERS USED: Rl, LINK, R15 


n positionals of form: (character, address) - Each 
positional "character" sub-parameter specifies an 


argument to compare against. The corresponding 
address sub-parameter indicates the address of 
the desired routine to enter if the character matches 


the argument. Register form is prohibited. 


OPERAND=(R1) - The address of the designated input 
character to examine. 


VERIFY CONSOLE CONTROL OVER JOB 

This macro tests COMFLAGS field of the PCE to deter- 
mine if the input source is a remote. If the source 
is a remote, the not OK routine will.be entered 
unless either the print or punch route codes for the 
indicated job specify the remote. Otherwise the OK 
routine will be entered. — 

REGISTERS USED: R1, LINK 


-JOBQE=(R1) - The address of the HASP job queue entry 


for the desired job. 


OK= - Address of the routine desired to be entered 
if the console has control over the job. The 
address may be the symbolic register containing the 
address if specified as "OK=(register,BCR)" or 
"OK=(relative register,S$BRR). 


HASP Command Processor - Page 4.5-20 


96 


HAS P 


NOK= - Address of the routine desired to be entered 
if the console does not have control over the job. 
The address may be the symbolic register containing 
the address if specified as "NOK=(Register,BCR)" or 
"NOK=(relative register,$BRR). Either "OK=" or 
"NOK=" parameters must be specified. 





Relocatability Aids 


SARR - ADD RELATIVE REGISTER 
This macro instruction is used in conjunction with 
SSRR to restore the specified register to refer to 
the true address of relocated information. 


register - Required - The symbolic register contain- 
ing the address to be made true. 


SBRR - BRANCH RELATIVE REGISTER 
This macro instruction is used in conjunction with 
SCOMGRUP to enter a sub-processor routine using the 
offset provided by the SCOMGRUP routine. 


condition - Condition required to be met in order 
to branch. If this parameter is omitted, no comma 
should be written to signify its omission. "Condi- 
tion code" may be specified by the character 
strings: (E, NE, H, L, NH, NL, Z, NZ, P, M, 

NP, NM, O or NO). : 


Register - Required - The symbolic register con- 
taining the offset. 


SSRR - SUBTRACT RELATIVE REGISTER 
This macro instruction is used to make an address 
pointer relative for possible relocation before 
next referral to the information contained at 
the address. 


register - Required - The symbolic register con- 
taining the address to be made relative. 
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4.6 OPERATOR CONSOLE ATTENTION PROCESSOR 


This processor is included in HASP only if the value of the 
HASPGEN variable &NUMCONS is greater than 0 (see Section 7.1). 
The HASP interface to OS Console euEDonee if &NUMCONS=0, is 
described in Appendix 12.15. 


4.6.1 Operator Console Attention Processor - General Description 


The function of this processor is to stage a read on a console 
whenever an attention is received from that console. 


4.6.2 Operator Console Attention Processor - Program Logic 


During HASP initialization, the first three words of the OS Console 
Attention Routine (IEEBAl1) are overlayed with instructions which 
cause IOS to enter the HASPATTN routine of this processor whenever an 
attention interrupt occurs. 


When an attention request is signalled by a console device, HASPATTN 
saves the device address in the processor! s PCE workarea, $POSTs 
the PCE, and POSTs HASP. 


When the Attention Processor is dispatched, it locates the physi- 
cal console whose address is in the processor's PCE workarea and 


links to the $WTO Processing Routine (see Section 5.7) to queue 
a read on. that console. 
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CHECKPOINT PROCESSOR 
CHECKPOINT PROCESSOR - GENERAL DESCRIPTION 


The purpose of this processor is to write the necessary infor- 
mation onto disk to affect a subsequent restart of the system. 
This processor will write the information at a predefined time 
increment and at the completion of each stage of each job. | 


CHECKPOINT PROCESSOR - PROGRAM LOGIC 


The first entry into the Checkpoint Processor is into a sec- 
tion which initializes the processor. This section issues a 
&GETUNIT macro-instruction to obtain a DCT for a disk and 
completes this DCT by inserting the event wait field address, 
track to be written, and the buffer address. 


The information to be checkpointed consists of the Job Queue 
which contains the status of each job in the system, the track 
allocation map which indicates the track groups of each disk 
that have been assigned, a save area which contains added in- 
formation as to the status of the system, the print checkpoint 
table which is used to effect a warm start of the jobs being 
printed, and (if generated) the Job Information Table which 
contains additional information concerning each job in the 
system. The Job Queue and the Job Information Table reside 
within the checkpoint buffers, but the remaining fields must 
be moved into these buffers. 


The track allocation map is the first to be moved and the 
track groups that have been reserved for the jobs that are 
currently executing and reading in are returned to the track 
allocation map to avoid loss of tracks in case of an emergency 
restart. Next the write buffers are completed by moving the 
Save area and the print checkpoint tables. An SEXCP is issued 
to write the checkpoint buffers and a $WAIT on I/O is initiated. 


The Job Information Table (if generated) is written with CCW's 
which are chained to the CCW's used to write the rest of the 
checkpoint information. The Job Information Table is not 
written with each checkpoint but only when the processor 
which requests the checkpoint indicates that he wishes the 

JIT to be written. This indication is made by setting the 
"JITICKPT" bit in the "SJITSTAT" field to one. 
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At the completion of the I/O operation, the HASP ECB is posted 
and the timer is reset to a predefined time increment that was 
specified as a HASPGEN parameter. A test is now executed to 
determine if the previous write was successful and if SO, A 
SWAIT macro-instruction is issued to place the processor into 
an inactive state until the time increment has expired or a 
Stage of a job is completed. 


If the previous write was unsuccessful, a message is issued 
to indicate to the operator that a restart is needed and a 


permanent HASP SWAIT state is entered so that no further check- 
point will be attempted. 
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ASYNCHRONOUS INPUT/OUTPUT PROCESSOR 
ASYNCHRONOUS INPUT/OUTPUT PROCESSOR - GENERAL DESCRIPTION 


Since the completion of all HASP I/O operations are signalled 
asynchronously with HASP operation via IOS channel-end appen- 
dages, these completions must be queued by the appendage 
until all HASP processors can be synchronized to receive the 
notification. The purpose, then, of the Asynchronous Input/ 
Output Processor (SASYNC) is to, at non-interrupt time, 
notify all processors of their I/O completions which were 
indicated by the OS I/O supervisor at interrupt time. 


ASYNCHRONOUS INPUT/OUTPUT PROCESSOR - PROGRAM LOGIC 


The buffers (and respective IOBS) associated with I/O channel- 
ends are chained, by the HASP channel-end appendages, for 
later processing by SASYNC. In addition to the POST of the 
HASP task by IOS on any I/O completion, the channel-end appen- 
dages also S$POST the Asynchronous Input/Output Processor to 
initiate its processing when the HASP task receives control. 
When SASYNC receives control, it dequeues the first buffer 
from its chain of work (operating disabled, for this operation 
only, since its chain is updated at interrupt time). The 
Device Control Table entry (DCT) associated with this buffer 
is located and the active I/O count for the device is reduced 
by one. Next the user's EWF address is extracted from the 
buffer and interrogated, and action is taken according to the 
following algorithm: 


EWF = 0 User does not want notification of completion 


of I/O operation (always a write). The buf- 
fer will be returned to the HASP buffer pool 
by SASYNC. 


EWF > 0O SPOST the "I/O" bit in the EWF specified and 
take no further action. 


EWF < 0 Enter a user provided routine at the address 
specified by the absolute value of the EWF 
field. Addressability for the processor 
routine is established and the address given 
is entered via the Branch and Link instruction 
with the buffer address in register "Rl." 

No further action is taken upon return by the 
processor. 


After performing the indicated action, S$ASYNC returns to dequeue 
the next buffer from its chain and the above procedure is re- 
peated. When the end of the chain is reached, SASYNC enters 

the SWAIT state until additional I/O completions occur. 
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4.9 HASP LOG PROCESSOR 


HASP Log Processor - General Description 





The function of the HASP Log Processor is to construct output 
buffers for eventual processing as part of each Job's printed 
output. Input to the Log Processor is through a queue of CMBs 
associated with the queue pointer S$LOGQUE which is defined in 
the HCT. The nature of the information in the input queue, and 
consequently the printed output, varies as a function of the 
HASPGEN Parameters &NUMCONS and &WTLOPT. 


4.9.2 HASP Log Processor - Program Logic 





Log processing of a message buffer is started by locating the 
corresponding execution PCE. PCEs for output buffers are found 
by using the job number in the buffer, and "reply" message PCEs 
are located by using the TCB address which is placed into bytes 
Six through eight of the buffer by the Operator Console Input/ 
Output Processor's asynchronous exit. Reply message processing 
is valid only for &NUMCONS>0. 


A test is made to ascertain if the message will fit in the HASP 
buffer currently being used by the job for log output. If space 
is available, the message is placed in the HASP buffer and the 
CMB is processed as follows: If the CMB status bits indicate a 
"read" or a "log only" condition, then the CMB is returned to 
the free queue via the routine SFREEMSG. The “log only" condi- 
tion is used when &NUMCONS=0. "Read" and "Write" have meaning 
only when &NUMCONS>0. If the status bits indicate a "write" 
condition, then the CMB is queued for display via the SWQUEBUF 
subroutine. 
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4.10 OPERATOR CONSOLE INPUT/OUTPUT PROCESSOR 


This processor and associated routines are included in HASP only 
if the value of &NUMCONS is greater than 0 (see Section 7). 

The HASP interface to the OS console support which is included 
1f &NUMCONS=0, is described in Appendix 12.15. 


4.10.1 Operator Console Input/Output Processor - General Description 


The function of the Operator Console Input/Output Processor is to 
process all I/O activity on all operator consoles. The processor 
also processes all console errors, making a number of retries. 

If the error continues, the message is ignored. 


4.10.2 Operator Console Input/Output Processor ~ Program Logic 


The Operator Console Input/Output Processor examines each entry 

in the console message buffer I/O queue, $BUSYQUE.. Each bit in 

the console byte is tested for an available console. If one is 
found the appropriate operation is initiated with a S$EXCP macro- 
instruction and testing of the queve is resumed. When all avail- 
able consoles have been processed, the processor enters a $WAIT 
condition until an I/O interrupt is received on one of the consoles, 
or until another console message is added to the queue. 
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4.10.3 Operator Console Input/Output Appendage - Program Logic 





The Operator Console neue vouceue Processor's asynchronous exit 

is entered from the Asynchronous Post Processor following the com- 
pletion of an I/O operation on a console device. The IOB completion 
code is tested for abnormal end, and if an error exists, an error 
routine is entered to retry the operation. 


If the completion is normal the appropriate physical console bit 

is shut off and the console byte is tested to see if the operation 
is complete on all consoles. If any bits are still on the Operator 
Console Input/Output Processor is $POSTed and an exit is taken. 


If all bits are now off and the operation code is a write, a link 
is made to $FREEMSG, the Enput/Ourpur Processor is $POSTed and an 
exit is taken. 


If the completed operation is a read, the response is processed 
according to type. If the buffer contains a HASP command (i.e., 
an input message whose first character is a dollar sign ($)), it 
is chained to the end of a queue for the Command Processor 
(SCOMMQUE), the processor is $POSTed, and an exit is made with a 
SPOST of the Input/Output Processor. 


If the message is a "reply", the reply number is converted to 
binary and the corresponding entry in SWTORQUE is located. Using 
the information in the entry, the message is moved to the WTOR's 
reply area and the WTOR's ECB is POSTed. The reply queue entry 
is merged into the free queue (SWTORFRE), and a link is made to 
the Log Queuing Routine. The Input/Output Processor is $POSTed 
and exit is made. 


If the message is not a "reply" or a HASP command, it is assumed 
to be an OS command. The message buffer is set to the proper 
format for the Master Command Routine and an SVC 34 is issued. 
When control is returned from the Master Command Routine, the 
buffer is released, the Input/Output Processor is $POSTed and an 
exit is made. 
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4.11.1 


4.11.2 


TIMER PROCESSOR 
TIMER PROCESSOR - GENERAL DESCRIPTION 


The function of this processor is to reset the OS interval 
timer after a timer interrupt has occurred. 


TIMER PROCESSOR - PROGRAM LOGIC 


This processor calls the IPOSTIT and ISETINT subroutines in 

the SSTIMER/STTIMER Control Service Routine (see Section 5.6), 
which causes the expired TQEs to be POSTed and the time inter- 
val specified in the first TQE in the TQE chain to be set 

into the OS interval timer. The processor then waits for 
another timer interrupt to occur. When the next timer interrupt 
is processed, the asynchronous exit routine $POSTs this pro- 
cessor and the above procedure is repeated. 
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4.12 REMOTE TERMINAL PROCESSOR (360/20-STR 





4.12.1 Remote Terminal Processor (360/20) 





- General Descripti 
The Remote Terminal Processor (RTP), although not a part of HASP 

proper, can be considered in the same catagory as other HASP processors. 

RTP is created by HASPGEN to operate as an extension of HASP ona 

System 360 Model 20 used as a remote terminal to HASP. RTP, in 

the Model 20, maintains constant communications with HASP at the 

central computer site via several classes of telephone lines to 1) encode 

and transmit jobs submitted at the remote site to HASP for execution on 

the central computer, and 2) print and/or punch the output from 

jobs thus submitted as the output Pecans available. Various techniques 


are utilized by RTP and HASP to obtain maximum performance of both 





the Model 20 devices and the communication lines used. RTP currently 
requires an 8K Model 20 with any reader and printer attached. The 
program can be made to operate in a 4K environment at a somewhat 
degraded performance. with reduced ease of operation. 

RTP has been designed to allow the addition of ''background" functions 
to operate in a multiprogrammed environment with normal remote terminal 


processing. 
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4.12.2 Remote Terminal Processor (STR Model 20) - Program Logic 


Upon completion of the loading of the RTP program deck, control is 
transferred to the initialization phase of the program to prepare for job 
processing. Initialization first checks the card reader for the presence 
of patch (REP) cards and, if present, makes the appropriate patches 
(the RTP REP card format is identical to the HASP REP card as described 
in Section 6.4). Encountering a /*SIGNON card within the REP cards, 
will cause initialization to replace the default remote SIGN-ON identification 
and password by the contents of the card. After loading REPs, or if no REP 
cards are present, the dynamic configuration card (which follows REPs if 
present) is decoded and appropriate commands for the system punch 
selected are established. (The formats of the SIGN-ON and dynamic 
configuration card are given in the Model 20 Operator's Guide-Section 11.2). 
The final process of initialization is the dynamic construction of the buffer 
pool. Buffers are built, according to the HASPGEN parameter &TPBFSIZ 
until the memory size of the machine is poached or the assembly parameter 
&NUMBUFS is reached. Construction of the buffer pool overlays the complete 


initialization routine. Control is then passed to the processing section of RTP. 
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The processing phase of the program consists of four principal processors 
and a communications adapter (CA) 1/O supervisor. Allocation of CPU 
time to the various processors is accomplished via a commutator. A 
processor is entered into contention for CPU time by changing its commu- 
tator entry from a NOP to a BRANCH command. Through the use of the 
WAIT macro, a processor may await the occurrence of a certain event 

and be entered, via the commutator, below the wait instruction upon 


completion of the event. 
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PROCESSORS 
Card Read Processor 

Upon initial entry, this processor checks the system card reader 
for ready status. If the device is not ready, HASP is notified, via a 
SEND EOT, of the lack of jobs to transmit, the CA receive processor 
is activated, the card read processor is deactivated, and entry is made 
to the commutator. If the card reader was ready, the transmission phase 
is immediately begun. Cards are read (double buffered) and are passed 
to the ENCODE subroutine which compresses and translates the card 
for transmission. The encoded card images are blocked in a buffer 
obtained from the dynamic buffer pool until the capacity of the buffer is 
reached. The buffer is then chained into a queue of buffers awaiting 
transmission by the CA transmission processor to HASP in the central 
computer. Another buffer, if available, is obtained from the buffer pool 
and is processed in a like manner. When, and if, the supply of buffers 
is exhausted, the reader processor enters a WAIT state to await the freeing 
of a transmitted buffer by the CA transmission processor. When the 
last card of the job stack has been read, a SEND EOT (zero word count 
buffer) is queued for transmission and the steps described previously 


are done to terminate transmission and activate reception. In order to 
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minimize CPU utilization, the card read processor-compression routine 
only compresses ''n'' or more blank characters (where ''n'' is the value 
of the assembly parameter &CCT). The format of transmission records 


to HASP is described in Section 12. 9.3. 
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Communications Adapter Transmission Processor 

The CA Transmission processor removes buffers from an ordered 
queue, dynamically being built by the Card Read Processor, and trans- 
mits their contents to HASP in the central computer. All transmissions 
are via the Communications Adapter-I/O Supervisor (CAIOS) which pro- 
vides for line re-instruct at interrupt time to make optimum use of the 
line (See CAIOS description). As posting of successfully completed 
writes occurs, the buffers are returned to the free buffer chain for 
reuse by another processor. This processor continues to dequeue and 
transmit buffers, as they become available, until a buffer with a trans- 
mission word count of zero is encountered. An EOT is then sent to HASP 
to indicate the end of the input stream, the CA Transmission Processor is 


deactivated and return is made to the commutator. 
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Communications Adapter-Receive Processor 


The CA Receive Processor is activated by the Card Read Processor 
when it is determined that no jobs are available to transmit to the central | 
computer. Upon being entered, CA Receive establishes communication 
with HASP in the central computer to await the output of a previously 
submitted job. The lack of jobs to transmit is indicated by HASP with an 
immediate EOT signal to the Model 20. When this EOT is received, the 
CA Receive Processor deactivates itself and activates the Card Read 
Processor to again check for the presence of jobs to send to HASP. 

If a job is avialable to be printed or punched, the CA Receive 
Processor activates the Print/Punch processor and immediately begins 
reading transmittal records into buffers obtained from the dynamic 
buffer pool. Buffers, thus filled, are placed in an ordered queue to 
await processing by the Print/Punch Processor. Au CA reads are 
via the Communications Adapter I/O Supervisor (CAIOS) which provides 
for line re-instruct at interrupt time to make optimum use of the line 
(see CAIOS description). Processing continues, as buffers and/or 
transmittal records become available, until an EOT signal is received 
from HASP indicating end-of-job. _A buffer with a word count of zero 
is added to the queue to inform the Print/Punch pigeounes of the end- 


of-job. 
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Communication is then, once again, established with HASP to 
ascertain if additional output for this job is available (i.e. the punch 
output of the job which has just completed printing). After the additional 
output has been processed, or if none existed, the CA Receive Processor 
is deactivated, the Card Read Processor is activated, and return is 
made to the commutator. Note that this logic, of activating the Card 
Read Processor prior to beginning processing output from the next job, 
allows the Model 20 Operator to interrupt print/punch processing, at 


a job boundary, to transmit a job to the central computer. 
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Print/Punch Processor 

When activated, the Print/Punch Processor begins dequeuing and 
processing bpultexs from the queue (being) created by the CA Receive 
Processor. Records to be punched are indicated by ''carriage control!’ 
characters of X'OFOF' and are routed to the punch section of the pro- 
cessor. In order to minimize CPU sonsiaaenati the print processor 
does not provide for 1-7/8 encoding of print characters (see Section 12. 9). 
The 16 4 of 8 Shivactens normally reserved for 1-7/8 encoding are re- 
defined for print records only, as additional print characters, thus 
yielding a 64 character print set. 

After reconstructing aah printing or punching all records in a buffer, 
that buffer is returned to the buffer ere use by another processor. 
When a buffer with a zero word count is encountered in the queue (indi- 
cating end-of-job), the Print/Punch Processor is deactivated, unless 
records Peeea the next job ieee already been queued, and return is made 
to the commutator. 

If a dynamic Sannaee eon card described the sy stem punch unit as 
DUMMY, eheounen section of the processor is dynamically altered (by 
initialization) to immediately free all punch eatied encountered in the 
Print/Punch buffer queue. This results in eliminating punched output; 


however, punch records are still transmitted to the Model 20. 
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By setting the assembly parameter &PUNCH to 0, all code concerned 
with processing punched output will be eliminated from RTP. The 
appropriate HASPGEN must be done on the central system to force all 


punch output for a ''punchless'' terminal to be processed locally. 
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Communications Adapter I/O Supervisor 

The primary purpose of CAIOS is to assure the maximum possible 
communication line utilization by re-instructing the line at the earliest 
possible moment after completion of a previous generation. 

All requests to read and/or write the communication line are passed 
to CAIOS for execution by the CA processors. Upon receipt of an I/O 
request, CAIOS immediately initiates the operation if the line is dormant, 
or queues the request to await completion of the currently active opera- 
tion. 

The completion of a CA I/O operation causes an interrupt which 
immediately transfers Soa to CAIOS. If the operation indicated as 
complete by the interrupt was successful (error free), any queued I/O 
reaueet is immediately initiated. The Event Control Block of the re- 
questor of the just completed I/O eueration is posted (with a X'7F') to 
indicate the successful completion of the request. Return is then made 
to the interrupted processor. CAIOS recognizes and attempts to 
correct all transmission errors encountered on any CA I/O operation. 
Since both CA processors are designed to double buffer /O requests, 


CAIOS insures virtually total line utilization during transmission periods. 
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4.12.3 Remote Terminal Processor (360/20)-Assembly Parameters 


The following indicates the variable name and function of certain RTP 


assembly parameters which can be of general use. 


&TPBFSIZ 


&NUMBUFS 


&CCT. 


defines the size of the buffers used for 
transmission to and from the HASP system. 
(Since this oaeisble must exactly agree with 
the corresponding ee in the HASP 
system, the values of both are automatically 


set at HASPGEN time. 


limits the number of CA buffers created 
dynamically at initialization time. Initial- 
ization will create buffers until the capacity 

of memory, or the value of {NUMBUFS is 
reached. It is suggested that this eice be 
made large enough to allow sufficient buffering 


(hence line load-leveling) to occur. 


represents the minimum number of consecutive 
blank characters which will be compressed 
by the Card Read Processor. This value 


should never be less than 4 and, significantly 
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& PUNCH 


 &MACHINE 


reduces CPU requirements by the Card Read 
Processor as it is increased. A wale of 80 
will effectively prevent all blank compre ssion 
(except on totally blank cards). The value of 
& CCT may never exceed 80. 

controls the existance of code within RTP to 
process punch salpae received from HASP. 

If €PUNCH=1, punching capabilities will exist 
in RTP. 

& PUNCH=0, no punching capabilities will be 
created in RTP (NOTE:. the HASPGEN of the 
central computer system must agree with this 
option. ) 

defines the Model of SYSTEM/360 on which 
RTP is to operate. This value must presently 
be set to 20. This option can subsequently be 
used to assemble RTP, at HASPGEN time, for 
any Model of SYSTEM/360 being utilized as a | 
HASP remote terminal. Although certain parts 


of this feature are currently in RTP, itis 


incomplete and totally untested. 
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4.13 REMOTE TERMINAL PROCESSOR (SYSTEM/360-BSC) 


The following sections outline the basic logic flow of the MULTI-LEAVING 
Remote Terminal Processor program for System/360 (including Model 20) 
workstations utilizing Binary Synchronous communications devices. The same 
workstation program is utilized for both the Model 20 and System/360 work- 


stations with generation parameters for the machine type. 


4.13.1 General Description 


The MULTI-LEAVING Remote Terminal Processor program is created by 
HASPGEN to operate as an extension of HASP on any Model of SYSTEM/360 
used as a canete workstation for HASP. This terminal program maintains 
constant communications with HASP at the central site via several classes 
of telephone lines to (1) encode and transmit jobs submitted at the remote 
site for OS/360 processing on the central computer, and (2) print and/or 
punch the output from jobs thus submitted as the output becomes available. 
Optionally, if an operator console is attached to the remote system, 
informational and control facilities are provided. All of the above functions 
may occur simultaneously. Various techniques are utilized by HASP and 
the workstation program to obtain maximum performance of the remote 
devices and the communications line. Figure 4.13.1 indicates the basic 


information flow through the system. 
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Figure 4.13.1 MULTI-LEAVING Information Flow Diagram 
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Remote Terminal Processor (System/360) — Page 4.13-2 


120 «+ 


HAS P 


4.13.2 Program Logic 


The MULTI-LEAVING Remote Terminal Processor consists of an initialization 
section, four principal processors, three communications interface processors 
and a communications INPUT/OUTPUT supervisor. Allocation of CPU time to 
the various processors is accomplished through a basic program commutator. 

A siceeeer is entered into contention for CPU time by changing its commutator 
entry from a NOP to a BRANCH command. A single control block, the Total 
Control Table (TCT) is utilized by all processors to provide for synchronization 
of concurrent operations, processor status information,re-enterability and both 
inter and intra processor communication. 

The following sections discuss the basic logic flow of the various 


components of the program. 
Communications Interface Processor - Output (STPPUT) 


This processor serves as the interface between the various input processors 
and the communications INPUT/OUTPUT supervisor. Its function is to compress 
and encode records for subsequent transmission to HASP at the central site. 
STPPUT is utilized as a subroutine by the various input processors and relieves 
the input routines of the responsibility of data compression and transmission 
buffer management. As records are submitted for transmission, STPPUT 


compresses the records according to a compression type generation parameter 
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(&CMPTYPE) and add the encoded record to its current output buffer. When 
the current buffer is filled or terminated, it is chained in an ordered queue 
for transmission to HASP by the esmmudieations INPUT/ OUTPUT supervisor 
and a — buffer obtained. Details of the compression and encoding . 


| 


technique utilized by $STPPUT are included as an appendix to this manual. 


Communications Interface Processor - Input (STPGET) 


This processor serves as the interface between the various output processors 
(Print, Punch, Console, etc) and the Communications INPUT/OUTPUT processor. 
Its function is to decode and uncompress transmission buffers received from 
HASP and to route the decompressed records to the appropriate processor for 
processing. STPGET is entered from the commutator and processes buffers from 
a ordered queue of received buffers established by the Communications INPUT/ 
OUTPUT supervisor. Records received are deblocked into "decompression 
tanks" and passed to the appropriate processor. Synchronization and passage 
of the tanks to the processors is accomplished through the Total Control Table 
(TCT) for each processor. S$TPGET additionally is responsible for metering 
the flow of each type of record from HASP. This also is accomplished by 
utilizing the various buffer and tank limits indicated in the TCT for each 


processor. 


Control Record Processor (SCONTROL) 


This processor provides synchronization between the various processing 
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functions at the workstation and the HASP SYSTEM at the central site. Control 
Records from HASP (i.e. Request to start a function, etc) are queued on this 
processor by the S$TPGET processor. S$CONTROL then processes the control 
record, transmits a response, if required,through $TPPUT and initializes the 


required functional processor. 


Communications INPUT/OUTPUT Supervisor (COMSUP) 


COMSUP maintains communications with HASP in the central CPU at all 
times and is responsible for the transmission of all data to and from the remote 
site. The data processed by COMSUP is always in compressed buffer form 
and passes to and from COMSUP via ordered queues estaulished by STPPUT 
and for STPGET. 

The communications I/O is primarily interrupt driven and is completely 
maintained by COMSUP (i.e. COMSUP is both the initiator and executor 
of communications I/O). During periods requiring no data transmission, 
COMSUP maintains a "handshaking" cycle with HASP at approximately 2 
second intervals to insure full bi-directional capabilities and to avoid 
unprogrammed "time-outs" of the adapter. 

In addition COMSUP maintains, verifies and corrects (if necessary) 
the MULTI-LEAVING block sequence checking feature and detects, logs 


and retries all communications errors. 
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Initialization Processor 


The Initialization Processor receives control from the loader and 
initializes the remote terminal program as follows: 
1. Ifthe CPU is not Model 20, general registers 1, 2, and 3 
are loaded to establish 16 K addressability. 
2. Replacement (REP) cards are read from READER | for possible 
modifications to the program. The format of the REP card 
is as follows: 
Col. 2-4 REP 
Col. 9-12 Replacement address - hexadecimal address 
of the first half word of storage to replace 
(if blank the previous REP card is continued) 
Col. 17=-n XXXX,XXXX,...XxXxx replacement data - 
one or more half word groups of hexadecimal 
data separated by commas 
Col. ntl blank - terminator for the eniscoment data 


Col. nt+2-80 comments - any text 


Each REP card is printed on PRINTER 1 when read as a record of program 
modification. REP reading is terminated when either a blank card (blank in 
Col. 1-5) or a /*SIGNON card is encountered. 

3. The HASP ENVIRONMENT RECORDING ERROR PRINTOUT (HEREP) 


is printed if the recording table is intact from the last execution 
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of the program; otherwise, a new table is created for future 
recording and print out. 
Interrupt PSW's are set for non Model 20 CPU's. 
The communication adapter is enabled and communications 
established with HASP as follows: 

a. Write SOH-ENQ to HASP 


b. Read for DLE-ACKO from HASP 


If I/O errors occur or HASP responses do not match the expected 
sequence, the sequence is repeated. 

The processor constructs a buffer pool over itself and queues 
the SIGN-ON record for transmission to HASP. 

I/O PSW's are set (I/O old points to commutator) and control 


is passed to the communication adapter interrupt routine. 


Print Service Processor - SPRTNI1 


The Print Service Processor's major functions are dequeuing decompression 


tanks containing print information from the printer Total Control Table, 


examining the sub-record control byte for carriage control information, 


performing required carriage control, printing the information on the designated 


printer, and releasing the used decompression tank to the pool. The processor 


also provides event control upon dequeuing and releasing the "tanks". If 


no console typewriter is attached to the system and the value of the user 


option &PRTCONS is not zero, the processor will set status information 
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at the end of each print data set which allows the console processor to queue 


Operator messages for printing. 


Iffput service Processor - SRRIN1] 


The Input Service Processor supports various card readers used for the 
purpose of submitting job streams to HASP and in the case of Model 20 
DUAL 2560 MFCM serves the functions of punch service processor. The 
processor provides error analysis and recovery for supported devices. 
Execution begins with the initial read routine which continuously attempts 
to read cards from the designated card reader. In the case of a DUAL 2560 
control is passed to a punch routine if the primary feed is empty. If reader 
is a DUAL 2520 or 1442 ~ routine will check the first card for blank and 
if sO pass control to the punch preparation routine; otherwise subroutine 
STPOPEN is called which sends a request to send a job stream to HASP. 
When permission is received the job stream submission routine is entered 
which reads cards into one of two decompression tanks calling the $STPPUT 
processor which compresses the data and schedules transmission to HASP. 
At end-of-file STPPUT iced to signal HASP and control is passed to the 
initial read routine. 

The DUAL 2560 eureh routine attempts to dequeue a decompression tank 
from the Total Control Table. If encecsenl the card image is punched and 
the used "tank" is released to the pool. The routine continues to dequeue 


- and punch for a maximum of 100 cards; this time tests are made to determine 
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the existance of cards in the primary feed. The tests are also made in the 
event of no tanks available for dequeuing. If the tests are negative the 
processor continues to punch cards; otherwise control is passed to the 
read routine following the initial read. The processor provides event control 
upon dequeuing and releasing decompression tanks. 
DUAL 2520/1442 punch preparation routine tests for: 
1. Operator signal - changing of the data dials, .SRl1 command, 
or unsolicited device end. (Depends upon configuration). 
2. Presence of Decompression tanks for punching. 
If the operator signals, the routine passes control to the initial read 
routine. Ifa "tank" is queued to the device Total Control Table control 


is passed to the Punch Service Processor (SURTN1). 
Punch Service Processor - SURTN1 


The Punch Service Processor's major functions are dequeuing decompression 
tanks containing print .nformation from the punch Total Control Table, punching 
the information into cards on the designated punch, and releasing the used 
"tanks" to the pool. The processor also provide event control upon de- 
queuing and releasing the "tanks" in addition to error recovery upon 
erroneous punching of data. If the device is a DUAL 2520 or 1442 control 
is passed to the Input Service Processor (SRRTN1) after servicing output 


"tank". 
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Console Service Processor - SWRTN1 


If the remote terminal has an attached operator printer keyboard, the 
console processor performs the following functions: 

1. Reads operator commands from the console keyboard. 

2. Examines the input for local commands (Model 20 only) 
passing local commands to the command processor and 
passing all other commands to HASP. 

3. Type operator messages contained in decompression tanks 
queued to the console Total Control Table. 

4. Convert codes in the error message log table to readable form 
and type the resulting messages. 

Execution begins with the processor testing for an operator command 
in the console input "tank" waiting to be transmitted to HASP. If so the 
console read in function is skipped and an attempt is made to send the 
command to HASP. Control is passed to the console output routine which 
tests for output meeeseeee If so, the processor dequeues the tank, types 
the message, and releases the tank. Control is then passed to the beginning 
of the processor. If no output messages are pending the console logging 
routine is entered which converts, types the message, and passes control 
to the beginning of the processor. The console read routine tests for 
operator requests and if so, reads the command from the keyboard, calls 
the STPPUT processor to compress the data and transmit the command to 


HASP, and passes control to the console output routine. If the remote 
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ceenies is a Model 20 the read routine tests for local commands and 
calls the command processor which in case of ".S" command , posts the 
appropriate Service Processor and returns. Local commands are not 
transmitted to HASP. 

The Console Service Processor without a console keyboard exists only 
when the value of the user option &PRTCONS is not zero. Execution begins 
with a test for printer availability. If available, any console messages are 
removed from the console output queue by the dequeue routine and attached to 
the printer queue, allowing the Print Service Processor to print the message. 
If no console messages are queued the processor will convert any log messages 
into readable form, move the resulting message into a "tank" obtained from 
the pool, queue it to the console output queue and pass control to the con- 
sole dequeue routine. If the value of &PRTCONS is one and the printer is 
not available console messages are allowed to accumulate to a maximum 
queue limit. If the limit is reached prior to the printer becoming otherwise 
available the printer is forced available and the messages are queued to the 
printer with the sub-record control byte of the first message set to skip to 
channel 1 before print. If the value of &PRTCONS is two and the printer 
is not available to the console the processor will dequeue console tanks 


and release them to the pool. 
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Total Control Table (TCT) 


The Total Control Table is the major working storage area for the unit 
record processors and is customized for each configuration and device supported 
by the remote terminal program. Each basic TOT field may be referred to by using 
symbols defined in the DSECT named TCTDSECT, however, each processor has 
the option of uniquely referting to the fields directly by using the alternate 
three ehaesete: prefix to aneh field name as follows: 
TCT = nial TCT prefix 


CCT 


Control record TCT 


PCT 


Printer TCT 
RCT = Reader TCT. 


UCT Punch TCT 


WCT Console TCT 


Appropriate DSECT's are provided by generation macros in the event more 
than one TCT of a given type is supported by the system. Basic control 
fields appearing only in systems with model numbers above the Model 20 
are as follows: 
NAME DESCRIP TION 
SpCTCOMn TCT addressability field - The commutator 
branches to this field to give control to the 
appropriate processor - the field contains a 


BALR R7,0 instruction which sets up TCT 
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NAME 


TOCTSTRT 


TCTENTY 


TCTRIN 


TCTCCW 


TCTDATA 


DESCRIPTION 


addressability for the processor - symbol 
characters "p" and "n" uniquely identify the 


TCT for the commutator 


First two characters of unconditional branch 


instruction 


"S" type address constant pointing to the 
appropriate processor - the field completes the 
branch instruction which passes control to the 


processor at the desired entry point 


Return to next entry in commutator - each 
processor waits by branching to this field 
of the TCT which in turn branches to the 


commutator 


Actual CCW op-code used in last I/O on the 
device - set by the processor and unit record 


IOS 


Address of data area used for last I/O transfer 


or address Of input "tank" currently being 


Remote Terminal Processor (System/360) — Page 4.13-13 


131 


Ages 
Se 


HASP 
NAME DESCRIPTION 
compressed for transmission to HASP 


TCTFLAG CCW flags 


TCTOPCOD Op-code which will be inserted into the 
TCTCCW field upon normal entry to unit record 


IOS 


TCTCCWCT CCW count field - length of data last trans- 


ferred or to be transferred 


TCTSENSE Sense information - set by unit record IOS. 


for error diagnostic purposes 


TCTUCB | Device Address - contains eeiaaitanid 
device address for SIO and interrupt recognition 
purposes - the high order bit of the field is set 
on by the processor when waiting for HASP to 


authorize job submission 


TCTECB | | Event Control Block - contains all bits stored 
in CSW byte 4 since the last SIO instruction for 
the device - busy bit is set at SIO and when 


the processor desires to wait for unsolicited 


4 
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NAME DESCRIPTION 
device end - busy bit is reset at device end 


TCTALTOP | Alternate op-code for DUAL reader/punch 
devices - processors requiring alternate op- 
codes have the option of setting the TCTCCW 
field with the contents of this field prior to 


entry to unit record IOS 


TCTSAVI1 Save area for the processor subroutine LINK 


register 


Basic fields which may appear in remote terminal programs for all 


360 models are as follows: 


TCTNEXT Next TCT in the chain of TCTs 


TCTFCS Function Control Sequence Mask - used by 


STPGET processor to setup the FCS transmitted 


to HASP for backlog control 


TCTRCB Record Control Byte - records from HASP which 
have RCB bytes identical to this field will be 


queued for output on the corresponding device 
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NAME DESCRIPTION 
TCTSTAT Status Flags - each bit has one or more meanings 


which are dependant upon the processor 


involved: 


bit 0 


bit 1 


bit 2 


bit 3 


bit 4 


bit 4 


TCTOPEN - always off indicating 

device is in use by HASP output 

(as appropriate) 

TCTACT - used by $TPGET to 

determine which output devices 

need more data - processors set bit 

1 when dequeuing output "tanks" 

TCTSTOP - device has been stopped 

and is awaiting a-.start command. 

TOT1052, TCT2152 - Seneuié 

device identifier 

PCT only = TCT1403, TCT1443, 

TCT2203, TCTPRISW - indicates the 

status of the corresponding printer - 
’ 

if setthe printer is available for 

printing operator messages 


WCT only = TCTREQ - console request - 


operator desires to enter a command 
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NAME 


TCTCOM 


TCTID 


TOTINRCB 


Ane 


DESCRIPTION 


bit 4 UCT only = TCT1442 - the device is a 


1442 with single stacker pocket 


bit S - RCT orUCT = TCT2540 - TCT is for 
a 2540 


bit 5 WCT only = TCTREL - release requested - 


an unsuccessful attempt has been made 
to sbiain a buffer for command trans- 
mission to HASP - the command is in 
compressed forin in the consoles "tank" 


waiting for a free buffer 


bit 6 RCT/UCT = TCT14420, TCT25600 - 
TCT is for a DUAL 1442 Reader Punch 


or DUAL 2560 MFCM 


bit 7 RCT/UCT = TCT25200 - TCT is fora 


DUAL 2520 Reader Punch device 
Pointer to corresponding commutator entry 


Optional field - two character identification 


for local command processors 


Optional field - exists when DUAL devices are 


attached to the system - identifies the Input 
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NAME 


DESCRIPTION 


Service Processor function as opposed to the 
Punch Service Processor function identified by 
TCTRCB - TCTINRCB is equated to TCTRCB if 


no DUAL devices are attached 


The following fields are normal device extensions and do not exist for 


card reader devices when DUAL devices are not attached to the remote 


terminal: 


TCTTANK 


TCTBUFER 


TCTTNKLM 


— TCTTNKCT. 


TCTBUFLM 


Beginning of output "tank" queue - output records 


appear in unit record image form 


Beginning of output buffer queue - contains 
records in compressed form waiting for de- 


compression into tanks 


Tank limit - maximum number of "tanks" which 


may be placed in the "TCTTANK queue 


Tank count - actual number of "tanks" queued 


to the TCT 


Buffer limit - maximum number of output buffers 


which may be placed in the TCTBUFER queue 


HASP 
NAME DESCRIPTION 


before signalling HASP to suspend sending the 


streams - limit is ignored for WCT | 


TCTBUFCT Buffer count - actual number of buffers queued 


to the TCT 


Reader and console TCT's have extensions which are used as "tanks" 
for records which are transmitted to HASP. These "tanks" belong to the 
device (2 for readers and 1 for the console) and are not released to the "tank" 
pool. The following field symbols are only defined for the TCT's with 


prefix designators. RCT, WCT, and with DUAL devices UCT: 
| RCTTANK1, RCTTANK2 "Tank" origin and working storage 
RCTTRCB1, RCTTRCB2 Input RCB for HASP identification 
RCTTSRC1, RCTTSRC2 #£Sub-record control byte = X'80' 
RCTTCT1, RCTTCT2 Count field - length of data portion 


RCTTDTA1L, RCTTDTA2 Data area - input card or operator command - | 


will be blank for the DUAL 2520 and 1442 


while in output status 
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4.14 REMOTE TERMINAL PROGRAMS (1130) 


Introduction 


The 1130 MULTI-LEAVING terminal program is designed to operate on a 
system with 8K words which contains the standard Binary Synchronous Com- 
munications Adapter. 


The unit-record equipment supported may include any or all of the following 


devices: 
® 1442 Reader/Punch or Punch 
e 2501 Reader 
@ 1132 Printer 
@ 1403 Printer 
® Console keyboard/Printer 


Programs developed for the 1130 in conjunction with the HASP Remote Job 
Entry feature are assembled using the OS/360 Assembler. The 1130 instruction 
set is generated thru the use of macro instructions (See Section 14.4.5) corres- 
ponding to the actual 1130 hardware commands. Additionally, pseudo (assembler) 
operations are sails to aid in the development of 1130 programs on the System 
360. 

oe object decks produced by the OS Assembler are subjected to further 
processing by a program (LETRRIP) which condenses and changes the format of 


the EBCDIC decks to facilitate 1130 loading. 
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The remote terminal system for the 1130 is composed of several programs 


briefly described in the following paragraphs: 


RTPBOOT - A bootstrap loader consisting of a single "load mode" format 
card and several column binary and EBCDIC program cards. The function 
of RTPBOOT is to "bootstrap" an EBCDIC format loader (RTPLOAD) into 


1130 core. RTPBOOT will load from either a 1442 or a 2501 card reader. 


RTPLOAD - Loads into the upper segment of defined 1130 core and then 
loads the main terminal program (RTP1130) into the lower extent of 1130 
core. RTPLOAD also processes REP cards and performs the initial pro- 


cessing of /*SIGNON control cards. 


RTP1130 - The main terminal processing program which provides the 


MULTI-LEAVING support for the 1130. 


The following sections provide more detailed information on the design 


and implementation of the above programs. 


a 
wil 
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4.14.1 Remote Terminal Processor (RTP1130) 





| Introduction 


The subsequent sections present the basic structure of the terminal program 
for the 1130. Included, are descriptions of the commutator logic and associated 
processors; system subroutines; processor subroutines; control] block formats 
and data block general formats. 

The documentation presented is intended to be introductory in nature. — 

The user intending to modify the system should use the documentation in con- 


junction with a program listing which contains commentary in much greater detail. 
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Commutator Processors 


Distribution of CPU time to the processors concerned with the functions 
necessary to support terminal devices is through programmed commutator 
logic. Each processor which needs CPU time and is dependent on external 
I/O device rates is represented by a commutator entry. The commutator 
entry consists of the following basic elements: 

e A named commutator "gate" which takes the form of a branch to 

the next commutator entry (gate closed) or a "NOP" if the entry 
is active (gate open). 

@ A long form branch to the active commutator main ~outine used if 

the gate is open. 

e A named return point for reference by the main commutator routine. 

@ A named end to the commutator entry which is the address of the 


next commutator entry. 


The basic structure as defined may also contain register save-restore 
sequences to be used for each entry-exit cycle through the commutator. 

The processors entry from the commutator (gate open) usually provides 
for a method of setting a variable entry to the segments of the processor 
which are involved with waiting for I/O to complete or some system resource 


to become available. 


fet i 
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The general operation of the commutator involves the opening and closing 
of processor gates, the setting of variable entry pein wie the processors, 
the initiation and associated wait period for I/O operations and the return to 
the commutator to "share" the CPU during wait periods. The last instruction 
i the commutator is a branch to the "top" or first instruction in the commutator 
which initiates the next cycle. The current system does not provide fora 
priority relationship among commutator processors. 

The main commutator processors contained in the RTP1130 system and 


briefly described in the following sections. 
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TPIOX - SCA Input/Output Control Processor 


Controls the transmission of data and/or control records between HASP 
and RTP1130 via the SCA. All adapter I/O is initiated using the SCA I/O 


Supervisor - BSXIOS. 


TPGET - Processor for TP Buffers From HASP 





Processes ve received from HASP in the form of TP buffers or control 

records preprocessed by TPIOX. Control record processing is in the form 
_ of "Request to start" or "Permission to send" functions. 

Data buffers are deblocked, decompressed, converted io aeuroptats 
codes (1403 printer, 1442 punch, etc.) and queued for the specified com- 
tated V/ O processors. 

Control information pertinent to the unique requirements of each data 


type is provided through the associated UFCB. 


TPPUT - Processor For Data Destined For HASP 
| Acquires a TP buffer from fe free chain and collects data from defined 
sources (card reader(s), console keyboard, etc.) to be processed (con- 
. verted, truncated, compressed, etc.) and inserted into the buffer which is 


queued for TPIOX transmission to HASP. 


tn 
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RDTFO - 2501 Card Reader Processor 





A conditionally assembled processor which supports the 2501 card 
reader as a job entry device. The functions of monitoring for a 2501 "ready" 
condition; reading eeede: requesting permission to transmit to HASP; waiting 
for permission to send; queueing data for TPPUT; transmitting "end-of-file" 


conditions and device error recovery are contained in this processor. 


RPFFT - 1442 Reader And/Or Punch Processor 


A Sendieeasis assembled processor which supports the 1442 - 5, 6 or 7 
ae a card reader, card reader/punch or as a cara punch only. The functions | 
to be performed are controlled by the assembly variablas chosen and the use 
of local operator commands, when applicable. The reader sections of code 
| monitor for a "ready" condition; reads cards for transmission to HASP via 
TPPUT; processes "end-of-file" communications and provide error recovery. 
The punch sections of code wait for data to be punched through interrogation 
of a queue developed by the TPGET processor and provide error recovery and 


and punch termination procedures. 
PRFOT - 1403 Printer Processor 


A conditionally assembled processor which supports the 1403 printer 
as a terminal output device. The functions of monitoring for input to be 


_printed; simulating carriage control operations; processing "end-of-file" 
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conditions; setting UFCB status information and error recovery are included 


in this processor. 
PRETT - 1132 Printer Processor 


A conditionally assembled processor which supports the 1132 printer as 
a terminal output device. The functions of monitoring for input to be printed; 
initialization of interrupt processing routines for the 1132 print scan opera- 
tions; simulation of carriage control operations; processing "end-of-file" 
conditions; setting UFCB status information and error recovery are con- 


tained in this processor. 


CONSL - Console Keyboard/Printer Processor 


Processes console keyboard input and prints on the typewriter messages 
originating from HASP or iafeeanl sources. 

Keyboard input is initiated by activation of the "INT REQ" key and by 
the interrupt routine which sets a flag and opens the console routine gate. 
Note: The position of the "keyboard/console" switch is not interrogated and 
input is assumed to be from the keyboard. The value of the console entry keys 
is read every communtator cycle and, if key ois on, stored in location 
SENTKEYS. All non-control character input is printed and the card code value 
stored for investigation at EOF time. If the first character of inputis "." 
(period) then the data is assumed to be a local command. All other data is 


transmitted to HASP for action as a HASP operator command. 
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Print input is obtained from a queue which originates locally and/or 
from HASP. Data to be printed may be EBCDIC or tilt-rotate code and 


black or red ribbon. 


RTPET = Initialization Processor 





This special commutator processor is responsible for the initialization 
functions necessary for the commencement of the 1130 terminal operation 


in conjunction with HASP. The major functions performed are: 


@ Sets the interrupt transfer vectors for RTP1130 operation. 

@ Dynamically builds the TP buffer pool using the defined extent 
of 1130 core; the end of the 1130 program and the defined TP 
buffer size. 

@ Builds a TP buffer containing the sign-on information processed by 
RTPLOAD for transmission to HASP. 

® Establishes SCA communications with HASP and prepares TPIOX 
for "sign-on". 

® Opens the commutator gates for all SCA and input processors. 

e Disconnects initialization from the commutator. 


@ Branches to commutator which initiates MULTI-LEAVING operation. 
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System Subroutines 


The following are brief descriptions of the major subroutines contained 
in the RTP1130 program. These subroutines are available for use by any 
System commutator processor with the restriction that they. may not be used 
at interrupt time. Detailed information concerning the calling sequences, 


input values, etc. may be found in the listing of the RTP1130 program. 
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SGETQEL - Dequeue An Element From a Chained List 


Given the address of a chained list, SGETQELreturns the address of the 
first element available in the list and removes the element and rechains the 
list. The chain field of the dequeued element is set to zero before returning. 


If the chain is null, an indication is returned to the user. 


SPUTFOL - Engueue An Element In A Free Element Chain 


Given the address of a free element chain pointer and the address of an 
element to be returned to the free chain, the element is returned to the free 
chain. The construction of the free chain is in random order depending on 


system processor utilization of the free element chain. 


SPUTAQL - Engueue An Element In An Active Chained List 


The address of an element supplied by the caller is used to build a 


chained list in first-in, first-out order. 
STPOPEN - Initiate Control Record Transmission 


Control record communications with HASP in the form of "Request to 
start" and "Permission to send" sequences is the function of this routine. 
Input includes an indication of the control record type and a pointer to the 


UFCB for the device being processed. 
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SSRCHB - Search UFCB Chain For Matching RCB 


The RCB code supplied by the user is used to search the UFCB chain 
for a UFCB with a matching RCB code. An indication of the status of the 


search is returned to the caller. 


SWTOPR - Type Message On Console Ty pewriter 


The caller supplies the address of a message in EBCDIC er with 
control information indicating red or black ribbon and the number of char- 
acters to be typed. The address of a routine to be given control in the 
event that the message cannot be processed immediately must also be 
supplied. 

‘The message is queued for processing by the console typewriter 


commutator routine. 


SLOGSCA - Log SCA Error Messages On Console Typewriter 





Error conditions associated with the SCA dperaticn are logged on the 
console typewriter for information and possible remedial purposes. The 
format of the message logged is: 

SCA LOG XXXXXXXX 

Where the value of "XXXXXXXX" is determined by the caller and is in 

fact the contents of the ACC and EXT on entry to the routine. 


An indication of the status of the request to log is returned to the caller. 
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SMOVE - Move A Variable Number Of Words 


This routine provides for the moving of a specified number of words 


from a source block to a target block. 
SXPRESS - Convert Card Code To EBCDIC 


The card code (12 bit) input is converted to EBCDIC using a high 
speed conversion algorithm in conjunction with a minimal conversion table. 
Special consideration is given to "blank" conversion under the assumption 


that most cards are dense with "blank" data. 


SXCPRNT - EBCDIC To Console Printer Code Conversion 


Converts a single EBCDIC character to the equivalent console printer 


Tilt-Rotate code using a table look-up method. 


SXPPRNT - EBCDIC To 1403 Printer Code Conversion 


Converts a single EBCDIC character to the equivalent 1403 printer 6 bit 


with parity code using a table look-up method. 
SXCPNCH - EBCDIC To Card Code Conversion 


Converts a single EBCDIC character to the equivalent 12 bit card code 


using a table look-up method and conversion algorithm. 


fa 
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STRACE - Trace Machine Registers 


Stores the information shown below ina table of variable length. Each 
entry is the result of the execution of the linkage created by the STRACE 
macro. The trace table created at assembly time is circular. 


Trace table entry : 


Word. Description 


1 Count of the number of entries for this $TRACE 
2 Location +1 of caller to $TRACE 

3 - Contents of ACC 

4 Contents of EXT 

x) Contents of XRl 

6 Contents of XR2 

7 Contents of XR3 


The count of the number of entries is also stored in the STRACE 
macro linkage. 


The assembly of S.fRACEisa function of the variable &TRACE. 


SSDUMP - System Core Dump 


A conditionally assembled subroutine which allows post-mortem or 
dynamic dumps on either the 1132 or 1403 printer. SSDUMP is assembled if 


&DEBUG SETA 1 is included in the RTP1130 source deck. Linkage to SSDUMP 
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via location 0 is also established so that a post-mortem dump may be 
taken by pressing suaien reset and sacs. 

The linkage to use this subroutine dynamically is contained in the 
system listing. Note: The logic of the subroutine does not allow concurrent 


operation of the selected printer and other devices. 
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Processor Subroutines 





The following are brief descriptions of the major subroutines which 
may be used by commutator processors subject to the restrictions that these 
routines are processor dependent in their operation. For example, the SCA 
I/O Supervisor (BSXIOS) is used at initialization time and by the TP buffer 


manager but cannot be simultaneously used by these commutator processors. 
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BSXIOS - Low Speed BSCA Input/Output Supervisor 


Processes requests for transmit, receive or program timer functions 
on the low speed binary synchronous communications adapter. BSX IOS 
initiates the requested function and prepares the interrupt programs for the 
associated interrupt processing of the desired functions. 

The status of the function performed by BSXIOS is contained in a com- 
munication cell which is addressed by a variable pointer word. A commu- 
nication cell is defined for both read (receive) and write (transmit) operations. 
Various completion codes stored in = cells provide the status of the function 
with respect to normal or abnormal termination. 

BSXIOS expects the caller to provide the address of an appendage routine 
to be entered at the termination (interrupt time) of every write operation. The 
purpose of the write end-of-operation appendage is to allow re-instruct (read 
operation) of the communications adapter as soon as possible after the write 


completion. 
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DBLOCK - Deblock, Decompress, Convert and Store Data From HASP 


Locates a record (defined by RCB) in a TP buffer as specified by a 
given UFCB, decompresses, edits and moves data to a selected target 
area. The target area must have the same format as described under 
"Output Element (Tank) Description". 

The operation of DBLOCK includes the priming of the output tank 
with an initialization value supplied by the user (usually the value of 
a blank for the associated device); the updating of control information in 
the UFCB; the setting of control information in appropriate fields of the 
output tank; the automatic entry to conversion and store routines unique 
to the device associated with the UFCB supplied and the communication 
of the status of the buffer being processed (end-of-file, end-of-block 


conditions). 
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TPCOMPR = Construct Records For Insertion In TP Buffers 





Constructs a logical record consisting of a physical input record . 
attached 1130 devices (card reader(s), console, etc.). The logical record 
constructed consists of the original input after code translation, data trun- 
cation and/or compression (optionally) and attachment of the control bytes 
necessary for HASP processing. The control bytes are per the standard HASP 
MULTI-LEAVING conventions. 

The options listed below are set at assembly time to generate the 
supporting code 

® No compression or truncation 

@® Trailing blank elimination only (truncation) 


© Blank and duplicate compression and blank truncation 


The current version of TPCOMPR assumes card code input. 


DBUGSCAL - Trace Routine For Low Speed SCA 


This routine is conditionally assembled as a function of " & DEBUG ’ 
and provides a trace of all SCA interrupts in the form shown below. Entry 
is from BSXIOS interrupt processing routines. External disabling of ie SCA 
trace function is provided through the entry keys. The trace table limits are 
preset to use the upper 8K of a 16K 1130 and must be changed either by 
assembly or by the appropriate "REP". See the program listing and refer to 


locations DBUGSTRT and DBUGSTND. 
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The trace table format is: 


Word Description 


1 Operation type (BSXIOPT) 

2 DSW at interrupt time 

3 BSXIOS Completion Code (BSXOPF) 
4 Location of interrupt 

5 Data received/transmitted 

6 Data transfer count 

7 Read or write sequence index 

8 Spare word 
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TPBUILD - Constructs TP Buffers 





Constructs TP buffers for TPIOX transmission to HASP. Data to be 
inserted and length of insert are sravided by aaer . TPPUT initializes this 
routine by providing the buffer to be used and setting pointers and variables ; 

The data to betaseried ieuauaily ake form a logical record as con- 


structed by TPCOMPR. 
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RTP1130 Control Block And Data Formats 





Chained List General Format 





All queues maintained within RTP1130 are of the chained list form and 
consist of free queues and free queue pointers and active queues and active 
queue pointers. Free queues are chained in a random fashion while active 
queues are maintained in a first-in, first-out order. The general form of 
a queue is: 


QUEUE POINTER Address of next element chain word. 
Set to zero if no element. 


ELEMENT CHAIN WORD. ¢ ©°* * Variable length element. 


ELEMENT CHAIN WORD *« e * Variable length element. 


e ° *Last variable length element 
(Chain Word Set to zero). 


Examples of chained lists are: TP buffers, console message tanks, 
printer data tanks, punch data tanks. The size and number of elements in 


the queue is variable according to the nature of the queue. 
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UFCB - Unit-Function Control Block Description 


Each device which transmits data to or from HASP via the communications 
adapter processors must be represented by a unit-function control block. 


The general format of a UFCB is: 


REFERENCE WORD DESCRIPTION ~ 
UFCBCNW 0 Chain — to next UFCB 
UFCBNFO ] Information word... 
Input: Byte 0 = Reserved 
Byte 1 = Input Code 
= 0 for IBM Card 
= 1 for PTTC/8 


= 2 for EBCDIC 


UFCBSAR 2 Status and RCB Code... 


Byte 0 = Status of unit-function 


= X'90' if request to start sent from 
input unit-function or if request to 


start received for output unit-function 
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UFCBFCS 


UFCBCOM 


UFCBFQP 


UFCBBFP 


UFCBBFC 
UFCBBFL 


UFCBPBP 


UFCBPBA 


10 


= X'AO' If permission to start 
received for input unit-function or 
if permission to start sent for output 
unit-function. 


Byte 1 =RCB code associated with this UFCB 


Function control sequence bit associated with this 


UFCB (and RCB) 


Address of commutator processor gate address for 


processor associated with this UFCB 


Tank free queue pointer for output devices or 


address of input element for input devices 


Queue pointer for active TP buffers for output 


devices or end-of-file flag for input devices 
Count of active TP buffers for associated device 
Limit of active TP buffers for associated device 


Buffer address of Current buffer being processed 


by TPGET processor 


Address of next RCB in buffer being processed 
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UFCBPBS 


UFCBPWD 


UFCBPRO 


- UFCBSTO 


ll 


13 


14 


‘Position indicator for next RCB in buffer being 


processed. Set to 0 if RCB right justified. Set 


to 1 if RCB left justified. 


Output device width = 2*W/P where W = actual 
width in characters and P = 2 for packed output 


tanks or P = 1 for unpacked output tanks. 


Address of data processing routine (usually a con- 


version program) for each character processed by SDEBLOCK. 


Address of routine to store data processed by 


"“UFCBPRO" program an 
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IPBUF - TP Buffer Element Description 


All data transmitted to or from HASP is contained in variable length buffers 


(variable at generation time) with the following general format: 


REFERENCE WORD DESCRIPTION 


TPBUFCW 
TPBUFST 


TPBUFCB 


TPBUFDT 


TPBUFHD © 


0 


l 


2 


3 


3 


Chain word to next TP buffer 

Reserved 

Buffer control word 

Byte 0 = 0 (Reserved) 

Transmit function... 

Byte 1 = Number of bytes to be transmitted minus 2 
for end sequence which is inserted by BSXIOS. 
Receive function... 

Byte 1 = Number of bytes received 

Timer function... 

Byte 1 = Number of program time interrupts processed 
before ending timer operation | 

Start of data area of length jhaiinad by "&TPBUFSZE" 


which includes... 


BSC header value indicating the function (Read, write, 


timer) to be performed as defined by SCA function indicators 
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TPBUFBF 4 Control sequence... 
Byte 0 = BCB 
Byte 1 = first byte of FCS 
_TPBUFFR 5 Control euuenee: es 
| Byte 0 = Second byte of FCS 
Byte 1 = RCB 
TPBUFSR | 6 Control sequence... 
Byte 0 = SRCB 


Byte 1 = SCB 
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Output Element (Tank) Description 


Local terminal output devices (printers, punch, etc.) receive data via 
elements or tanks which are built by the commutator routine responsible for 
processing TP buffers transmitted by HASP. The general format of these tanks 


is described below. 


REFERENCE WORD DESCRIPTION 


TANKWRDA 0 Chain word to next tank 
TANKWRDB l Reserved 
TANKWRDC 2 Control word 


Byte 0 = Reserved for device use 
Byte 1 = SRCB from record received 
TANKWRDD 3 Control word 
Byte 0 = Reserved for device use 
Byte 1 = Actual tank data count 
TANKWRDE 4 Start of variable length data area determined at 


generation time 


Note: The element chain word and the data area must start on even 


1130 word boundaries. 
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Object Deck Format 


The following is the format of the object decks (RPT1130,. RTPLOAD) | 


produced from OS/360 assembler output by LETRRIP. 


Text Card 


Column (s) 
l 


2-3 

4 
9-72 
73-74 
75-76 


77-80 


End Card 


Column( s) 
l 


2-3 
4-72 
73-74 
75-76. 


77-80 


Descrip tion 


'T' for text card identification 
Absolute 1130 load address 
Word count of data field 

Data field (maximum of 34 words) 
Checksum of columns 1-72 
Identification 


Sequence number 


Description 


'E' for end card identification 
Entry point to program loaded 
Reserved 

Checksum of columns 1-72 
Identification | 


Sequence number 
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REP Card Format 





Column (s) 


8-11 


12 


13 


14-17 


18 


Description 

Any legal EBCDIC punch 

"REP" 

Blank 

Load address format field: 

"L" for listing option where the specified load address 
corresponds to the OS/360 assembler listing. 

"X" for absolute 1130 core address 

Currently unused but usually punched "0" for continuity 
Load address for first data word and is incremented by 1 
for each additional data word. REP cards may be con- 
tinued by leaving this field blank 

Blank 

Format field for data following. Subject to same definition 
as column 6. 

Data field to be loaded in the location computed as a 


function of columns 8-11 


| en 
4 
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Columns 19 through 78 in the same format as columns 13-18 with the : 
exception of column 78 which must be blank. A blank in columns 18, 24,...72 
terminates the scan of the card. | 

Note: The "L" option causes the epeciaed data to be divided by 2 


for conversion from 360 byte data to 1130 word data. 
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Examples of REP Cards 


1. The following cards: 


Col 
0 00 11, 
1 56 23 


RREP LO02208 X4C00,LOO4E »X4400,XO00F 
RREP XT4FF »X0000,X71L01 


Would result in the code represented below starting in 1130 core 


location 1104 (Hex): 


1104 $B 3999L 
11,06 $TSL L5 
1108 $MDM O»-L 
110A $MDX Let 


2. The following cards: : 


Col 
Oo 80600 11 
1 56 23 


RRER LOL772 X4C18,XLFF8 


Would be ignored because columns 2-4 not equal to "REP" 
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4.14.2 Remote Terminal Main Loader (RTP LOAD) 


RTPLOAD is an EBCDIC format loader which is loaded by RTPBOOT 


into the upper part of defined1130 core. The 1130 core definition (which 


is a RMTGEN variable) is used to specify the origin of RTPLOAD. The format 


of RTPLOAD (and RTP1130) is given in Section 4.14.1 under Control Blocks 


and Data Formats. 


RTPLOAD also reads and processes "REP" cards as well as the optional 


/*SIGNON control card. 


The major functions of RTPLOAD are: 


Clears core from location 0 to "&RTPLORG-1" 
Tests for a 2501 or 1442 card reader and initializes the card 


read routine for the appropriate device. 


Reads RTP1130 program cards, performing the conversion from 


card code to EBCDIC and loading the data into the specified locations. 
Sets up the entry to RTP1130 when the end card is processed. 
Reads and processes REP cards, if they exist. 

Reads, converts and stores /*SIGNON and sets indicator for 
RTP1130 signalling existance if /*SIGNON encountered. 


Transfers control to RTP1130 
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4.14.3 Remote Terminal Bootstrap (RTPBOOT 


The bootstrap loader distributed in object form as shown in the subsequent 
pages is specifically constructed to "bootstrap" the EBCDIC main loader 
(RTPLOAD) into the core locations defined by "&RTPLORG" at RMTGEN time. 
RTPBOOT loads into lower 1130 core via the load-mode format first card and 
following binary program cards and EBCDIC conversion table cards. RTPBOOT 
will load from a 2501 or 1442 card reader which is wired for the load-mode 


sequence initiated by the console "LOAD" button. 
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Figure 4. 14.3 - Remote Terminal Bootstrap Card Format 





_Card No. 3. 









L. Card No. 1 
| (12-11~7 

) j1-2-9 

| |12-11-1-8 

| |12-11-7-8-9 








_Card No. 2. 











a2 7 
112-11-2-3-4-5 
















0-1-2-3-4 
11 

iblank | ) 
[d2-11-1-40 ft - 


}12-11-0-1-2-4-5 
112-11 

blank — | 
[12-11-1-5 













111~0-1-4 | 
'12~11~0-1-2~3-4-5 | 
|11-0-1-4-5 
j12-11-0-1-2-4 
li1-0-1 

12-3-4-5 


\1-2 
112-11-0-1-4-5 

















}12-11-3 
12-11-1-2-3 






| |12~11-1-4-7-9 
| |12-4-8 
| |12-11-1-4-9 
| |12-11-3-4-6-9 













| (l1i-0-1-4 
- : | 112-11-0—2 


aes 








| | |L1-0-1-3-4-5-6-7-8-9|4 __[12-11-0-1-4- 
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Figure 4.14.3(CONT) - Remote Terminal Bootstrap Card Format 





Card 

Col. Card No. 1 Card No. 2 Card No. 3 Card No. 4 
41 0 
42 11-2-3 
43 12-0-1-3-5 
44 


11-2-3-4-5-6 


9 | 
11-0-1-3-4-5-6-7-8-9 


Mm Or tm 
Lo NO Fe 


1S! 
> 


Up kk Lif 
Owe on anu 





Sa 
or) 


DAADANA AA Wi i 
Mm WH FOO OnN A 


11-0-3-4-5 
0 
2 


mo 1 VN SS ss S SNSI O ON ON ON 
iOwoononurf WD FIO W!O ON A 
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Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format 





8 


_Card No. 


7 


Card No. 


a 


__Card No. 


5 


Card No. 


omen te 
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Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format 


Card 





8 


Card No. 


Card No. 


Card No. 5 Card No. 6 


Col. 





HASP Remote Terminal Processor (1130) - Page 4.14-37 


177 


HASP 


Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format 


y 


CARD 1 


99$99999999999999999999 
&4 n 


33 60 6! 62 65 E65 67 68 63 70 73 74 13:16 77 78 79 89 


BO 
‘ at a oe x1 : 7 mor nage a “7 os ne ee 
PEEP Ge GEFEN ie GOES FLEA USI ETRE Rae eae Ok Ply 3 Sebe RIUM OE nA, OLINGER ME ng ME ME LNG BRS GED La Cad GES eae OP TER ANE URLS Ay DS UCR UE ha 








HASP Remote Terminal Processor (1130) - Page 4.14-37.1 


178 


HASP 


Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format 


CARD 3 


A Eitri i be: ed ait i oid 
PE Piiaitiiiiad & Pia iim ani: e&:r sed e&aiiid #4 
OOO OPP OCOOR MBAR CORB 000 cof cof 008 of ORD OB OBR CBB ooo ooBM cob och ooWocoocBoccofooob oka 
12.3 4645 6 7 8 9:10 11 12:13 14 15 16 87 16 19 20 20 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 33.49 41:42 43 46 45 46 47 49 49 50 5) 52 53 S$ 55 SE Ss 52 55 60 Gt 62 63 64 65.05 €7 €8 ES 70 21 72:73 74 1S 76 77 78 79 80 
ey oe | eee DT ee) Ge) ee) GO) Oe) Gee) | oe) oe) |) | |) Pee eeeenen! 6) Seen) Bt Dene 
M22 2228222228 2822222228 2228 2222222222222 28 2 2222222228 222228 22222228 2222222 
03333303333303330308 3300 3308 333338 338 338 33 38 33338 38 338 3388 3 3833333338333338Ns ok 
ees CF ed cl) EERE) LD) cee) Oe) eee) ©) eee) ©) ee) ed ee) ees) Cee) eee ee 
SUMS SSSSHSMPSSHSSSSSSSSMBSSSMSSSSMPMB SB SA SHS SSB SSM SM SESH SEs sshssssshsssshsiss 
GEE EGESECCE6GECEGEGEEEGES EEE EECBGECEGEEGGEGECS CCGG GEGEEGGEGEGEGGCCESCEGEGGEG6GEEEE 
DUVTVTVIVTTTT TTT TIT TTT T0000 0007700000090 90990 099099990007 1 
STEELE EEE LLL LEE LLL LEE EEE LLL LLL 


9999999999999999999999999999999999N99INII999IINIIIIIIFIIITIIIIIIIIIIIITIIITIIIIIGSY 
12345678 23 “4 cr St 63 


oro 12:13 143 2 é 3 7 : ail 5309 61 62 63 64 65 £6 67 £9.69 7) © 72:73:78 75 75 7) 13 79 80 
ees Aa 


= <o 


wn 
~ 
wn 
ott 
~ 
—_ 
co 
_ 
wo 
a. 
Q 
~ 
om 
~ 
AS 
n 
‘= 
n> 
ae 
" 
nm 
Led 
nm 
nN 
~d 
aw 
oa 


CARD 4 


Hil 68 Hai od a i | aa | | | E bi @ Be @ 

ioe gua § ° Hl GUG 88 Gf Gaaaaad ad E Hadad d@ Hb. g6 8 OG 
OCOCORRA ORB 0000000000 00g ORB OAR BARR 000BB OB ooBB co oBocoPoooconnnBocB oof ookoocoon aka 
123 45 6 7 8 § 10 18 12 13 14 15 36 17 18 19 20 21 22 23 24 25 26 27 28:79 20 31 32 33 34 35 36 37 38 3S 40 41 42 43 44 45 46 47 48 49:50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 63 69 70 72 73 74:75 76 77 78 79 86 
i oe Oe Rees OP ee) eee) eee) ee) ee ee) el el Gee) Bee) Bees) Been! Reel lee Gee 
228222822222222282222 2008 28 2228 28 28 2222228 22228222288 222228228 28 22 2822222282222 


339333033983333333339 3308 383338333833333388 3388333388333333333383338830333383333 


Wo Pees COR ee eee eee! Peel led tee) ees Pee! Ol Oe) POPP ee Peer errl CeCe rere 
SSHSHBPSSHSMSMMRS SESS SSSR SA SBMA SSSA SB SSM SSR SM SAS SBS SHS SSSA S SMM SSSSSMESHSAss55555 


GEGG6G66566E6G6E6EGEEEGEFECEEEECESE EEE EEC E EE FE CE EES EGG EE EEC EGEGEE EEG EGESE6 EGE EG GE GEES 
PUVVVVVTT TTT DTT TTT TTT dddddddddd9d991991907 
GQGSESSERHSHRSHRHSEB SSH SHBH SHS BHG SSH SKSSGBSSSGS SSBB SSSESSERBESHEGRERESGRE RSE RES 
§99999999999999999999999 

a re rar prea parece 


W112 13 14 15 16 17 18 19 20 at 22 23 
ip 590 
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Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format 


CARD 5 





Ce ek ne 
O11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 3839.40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 $7 58 S960 61 G2 62 64 G5 66.67 88.69 70 M1 72 13:76 7S 16 77 78:79 80 
PETE ETEPEP PP TA PTA TPT ETT TET 
2282222222922 2222222222222222222222222222222222222222222222222222222222222222222 
33393333333933333333333333333333333333333333333333333333333333333333333333333333 
SAAAMAGSAAAIBAGAAGA GGA GGAAAGAAGAAA AAA GAAGAAAAASGAGAAAAGAA AAA AAAAAAGOAA AAA GK ES 
99555855555559555555555555555555555585555555555555555555555555555955555555555555535 
GEGGEEMCECEEGGHGGEGCEGESESGCGESSESGGEEGGEGGGEGEEECSG6EEGEEEEESEESEEESEGEEGEEEEEEE 
PUVVVTTE TTT TTT aad 


Pertrers Prveteuseeresaemee ser reeneinensts tees yenete sentenenasOneeAtnnt 




















G8388888E 





to 
(J) 
to 
6 
(a) 

2 ts 
C&> 
c=) 

2 2s 
2 
Cd 
co 
eS 6s 
CoD 
C 
Ce 
(z=) 
Ce 
6&2 
cea 
Ce) 
es 
tS 
ce 
> 
t2 
Ew 
[o=) 
co 
to 

: co 
Cee 
6D 
to 
&£ 
to 
(y=) 
yn 
[J =) 
CL 
[3 
(~] 
6 
(7 =) 
(Fo) 
co 
Ch 
oe 
to 
6 
>) 
at te 
co 
> 
co 
to 
t2 
a=] 
6 
es 









ie we 7 fo fo fae eg 
fen re Som fm Gon prey be 
me ie ike oe ao ee fee 
ce tt fim Bey By a Ba 





PEELE LLELELLGL 900000000 0BBRBRBS000c00000000000B8RURRRERRROEHE 
7 18 19 20 21 aaa ag 31 32 33 36 35:36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 $253 54 55 56 57 58 59.66 61 62 63 64 65 E5 67 63 69 79 Tt 72 713 74:75 JE 77 78:79 80 
RRRERRREEREEEED! PEROERREERPEEEE) SERRE EPOREEEEn) EREREEREREOEEE 
, 0 2222222822222228 22222228 22222228 22222828 2222222822222 
$9338393333339833333338333333382333333839222238332333383333333033333338333333383333 
4444844444448 44444448 44444449 44444448 44444440 44a aa aaa aaa gagasbaaaaaaghaagg 
§55955855555558555555595555555855555558555555585555555855555558555555585555555855 
GESGCCGHGEGEGE6ECHRGGGCEGESHGGGCGGGHGGGG6CGCGRGEGGG6SRGSEGGECRGGESSEGB GG ESEG CBSE GEG EGS 


ee EE ee a 












1770707787777777877777778 
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Figure 4.14.3 (CONT) - Remote Terminal Bootstrap Card Format 


v 


CARD 7 


TELE a PELE CECE LOE ELE DEE EERE 
BEER GUERUGRERGE GREGTGE BERGRREEE EEE LPREREECBEEL 
COCOOOCOOOCOCODCOOR BARR ERD ED OBBRRRBRRBRRREB 0000 0OcBERBRBEBBSSBRBER C0 cc00000cc00000 


12.3.4.5 6 7 8 9 $0 W 12 13 14 15 16 17 18 19 20 22 22 23 24 25 26 2) 22 29.30 3t 32 32-34 35 36 57 22.29 4% 41 42 43:44 45 46 47 42 69.50 51 52 53 54 55 56 57 Sa $3 50 $° Bo 63 64 C5 66 67 68 69 70 Tt 72 73:74 75 76 77 18 79 80 


1} RERRREE) GRREEES! PRREREE! CEREEEE! SERREEE! BEEEED) | BER RORREEEORES! | RERRRERE ORDERED 


222222222 22 22222 2222 222228 22222 
3330333333393333333833333338 33333338 33333338 33333338 33333938 33333338333333383933 


eel PUCeeees PUCCCee) COPUeer! CPE erer) OCC eT) PUPP VEe) CPUEPers CUPEREES COPERE ET) Pee 
SSSSSPSSSSSSSMSSSSSS SPSS SSSSSMSSSSSSSMSSSSSSSBSSS SS SSMS SSSSSSM555555SM5555555Hs 5 
BEGEEEMCCEGSCCRGCECCCGHGGS6GCCHGCGECCCMGGGCCECHGCCCG6GGCMEGSESEGRGEGE6GGSMG6GGCGGGHS 
7777779809707790870799799800797798 70979797008 90007007087997972980007077080070797978777777:708 
eT Ee ee eee Eee ee 
HURsscococ9SMMRMANNS 999999 9HMRBDHHR sasascgsasogsa9oHssaasagsaaasaa9Naaaae9 


2 9:10 19:12 13:14 $5 16 17 18 19 20 21.2223 24 25 26 27 28 25 30 M1 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 4849 50 51 52 53 54 55 56 57 Sd Sah. f° €2 3:64 55 66 67 GE 63 70 O72 73:74:75 18 7? 18 79 80 








CARD 8 


BRRRRBRRRRERGTEEE | 
BHRRGERREEER RAED 7 
OCODKOODOKDNKOKDDKOKNDKDNKKOOORRRARBRRARBRRERAR COOOOc0cOOOo DOD ORAMAAAABoooo000 
34.5 6 7 B 10 Hh 12 13 14 15 16 17 18 9 29 2 22 23 24 25 26 27 28 29:30 31:32:33 346 35 36 37 38.35 40 41 42 43-46 45.46 47 48 4950 St 5253 54 55 56 57 58 59 60 G1 &2 63 64 65 66 67 GB 69 70 7) 72 73:74 75:16 77.78 79 80 
BESEERt REREEE! | PRREEEE) PEERED! | BERGE EE! BEGEEE | CEEEEEE! BEREEEE! CEREEEE) EECEEE 
222222282222222H2222222M 22222228 22222298 22222228 22222228 22222228 22222228 22222 
3$3303333333833333338333333383333333833333338 33333338 3333333833333338333333383333 
Tees Peeeeers PECeeee) Ceeeere) PUCeree! Peererr! Pererer! Pererers Peereres Peerrers Pewee 
§5555855555558555555585555555855555558555555585555555855555558555555585555555855 
GEGCCSHCEGGGGGRGGEGECGGCHGGGGGCERGSGSCOSGMGGECEGSCHGGCGEGGCRGGE6GECHGGGG CGSB GGGECGGES 
PEE peer e nena Ane ee ey ee ee 
Pees s CM MPM MMMBRscsecccHBRBMBNON sssscccHBRROSHMBssccsccMMNNGMRRsscscessQHBe 
BHGHERURGRRRRREURRRRRRRRARG BREE RRR R RARER RARER ERR ORR RB RE RRR RARER BERR AEH 


123456 § fea) 12.13.1495 16 17 18 13 20 20 22 23 24 25 26 27 22:23 90 51 32 33:34 35:36 37 38.39 46 At 42 43 44 45 46 47 48 49:50 51 52 52 54 96 56 87 59 5960 £1 €2 65 64 65 08 67 69.97 13 N12 713 :714:753 
Los cn 


g0 
12 
al 
22 
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LETRRIP (Loader for Eleven-Thirty Relocatable Remote Interleaving Processor) 
is a 360 program executed under OS/360 as part of the RMTGEN procedure. 
The purpose of this program is to condense the object deck produced by the 
360 assembler; relocate address constants according to the requirements of the 


1130 and to produce a new object deck in the format as described in Section 


4.14.1. 





HASP Remote Terminal Processor (1130) - Page 4.14-38 


182 


HAS P 
4.14.5 1130 Instruction Macros 


The 0OS/360 Assembler Macro instructions listed on the following 
pages are used to assemble the RTP1130 and RTPLOAD programs as a 
part of the RMTGEN proces&S necessary to create the 1130 workstation 
program. 


The general format of the instructions to be assembled with the 
macros is: | 


LABEL SOP ADDR,TAG,FMT,MOD 


Where: 


"LABEL" is the statement label subject to the OS/360 assembler 
rules and restrictions. 


"SOP" is a macro from the set listed at the end of this section. 
"ADDR" is the address field of the 1130 instruction. 

"TAG" is the index register (TAG) field of the 1130 instruction. 
"FMT" is the format indicator for the 1130 instruction: 


FMT=L for long form 

FMT=I for long form indirect address 

FMT=X for short form absolute address 
FMT='blank' for short form relative address 


"MOD" is the modifier bits field required for some 1130 instruc- 
tions. 


Listed below are some of the conventions which must be followed to 
successfully use the macro package in producing a program for 
operation on an 1130. 


i All symbols starting with the character "$" are deemed to be 
absolute in value. 


2 The symbols WA, WB and WC are assumed to define absolute values. 
Note: WA, WB and WC cannot be used as the first two characters 
of any relocatable symbols. 


ce All other symbols are assumed to be relocatable as defined by 
the 0OS/360 assembler SRL. 


4. Parenthetical expressions are considered to be relocatable if 
contained in an instruction, e.g., 
SAXT (*-*) ,WA,L 
is considered relocatable, where. 
SAXT *-* ,WA,L 
is considered absolute. 
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1130 Instruction Macros 


Macro Form 


$LD 

$LDD 
$STO 
$STD 
$LDX 


SLXA 


ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 


ADD, TAG 


ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG 

ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 
ADD, TAG, FMT 


ADD, TAG, FMT 


Description And Notes 


Load ACC 

Load double (ACC, EXT) 

Store ACC 

Store double (ACC, EXT) 

Load index 

Load index from address. A variation of $LDX 
with F=1 andTA=1. 

Address to index true. Identical to $LDX. 
Store index 

Store status 

Load status 

Add 

Add double 

Subtract 

Subtract double 

Multiply 

Divide 

Logical AND 

Logical OR 


Logical Exclusive OR 
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Macro Form Description And Notes 

$SLA ADD, TAG» Shift left ACC 

SSLCA ADD, TAG Shift left and count ACC 

SSLC ADD,TAG Shift left and count ACC and EXT 
SSRA ADD, TAG Shift right ACC 

S$SRT ADD,TAG Shift right ACC and EXT 

SRTE ADD, TAG Rotate right ACC and EXT 

SBSC ADD, TAG, FMT, MOD Branch/Skip on condition 
SBOSC ADD, TAG,FMT,MOD Branch/Skip and reset interrupt 
SBP ADD, TAG, FMT Branch ACC positive (long) 
SBNP ADD, TAG, FMT Branch ACC not positive (long) 
SBN ADD, TAG, FMT Branch ACC negative (long) 
SBNN ADD, TAG,FMT Branch ACC not negative (long) 
SBZ ADD, TAG, FMT Branch ACC zero (long) 

SBNZ ADD, TAG, FMT Branch ACC not zero (long) 
SBC ADD, TAG, FMT Branch on carry (long) 

SBO ADD, TAG, FMT Branch on overflow (long) 
SBOD ADD, TAG, FMT Branch ACC odd (long) 

SSKPP Skip ACC positive (short). 
SSKPN Skip ACC non-zero (short) 
SSKPZ Skip ACC zero (short) 

SSKPO Skip overflow off (short). 
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Macro Form 


SSKPC 


SSKPX — 


SB 


SBSI 


STSL 


$SMDX 


S$STL 


SMDM 


SWAIT 


SBSS 


SBES 


ADD, TAG, FMT 





Skip carry off (short) 


Skip ACC not equal zero and carry off (short) | 
Branch unconditionally. FMT = L or I generates 
long form SBSC with MOD = 0. 


FMT = X or blank generates $MDX ADD, TAG, FMT 


ADD, TAG, FMT,MOD Branch conditionally and store IAR 


ADD, TAG, FMT 


ADD, TAG, FMT 


ADD,FPMT 


ADD, VALUE 


ADD, TAG, FMT 


N,X 





HASP Remote Terminal P 


Transfer and store location counter. Assembled 
as a $BSI with FMT = L,MOD = 0 (long form 
unconditional branch and store TAR) : 

Modify index and skip 

Store location counter. Assembles ae SSTX 


ADD,0,FMT. 


Modify memory. 


Wait for interrupt 
Execute I/O 

Block started by symbol 
N = number of words, 

X = E for even storage. 
Block ended by symbol 
N = number of words 


X = E for even storage 
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Macro Form 


SNULL 


SADCON ADDR 


SNOP 


SZAC 


Description and Notes 


Null operation for symbol definition 
Address constant. Assembles as an 
absolute 1130 address. "ADDR" must 
be a relocatable symbol by the OS 
assembler definition. 

No operation. Assembles as S$SLA 0 


Clear ACC. Assembles as SSRA 16 
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4.14.6 


GENERAL INFORMATION 





0S/360 ASSEMBLY OUTPUT 





If the value of &FULLIST is set to 1 at the time of generation 
of RTP1130 or RTPLOAD then the listing produced by the 0S/360 
Assembler will contain the following information: 


1. The location counter value for each 1130 instruction or 
storage location in terms of bytes. The actual 1130 
location in terms of words can be determined by dividing 
the displayed value by 2. The REP facility allows a 
specification of either byte or word form. 


2. The 1130 instruction is printed in 1130 format. The long 
form address is in terms of 1130 words and the short form 
is true relative format. 


VARIABLE INTERNAL PARAMETERS 


The generation of the RTP1130 program using RMTGEN provides 
the user with a simple and flexible means of changing common 
parameters germane to the configuration of the 1130. Addi- 
tional internal parameters may be varied by using the source 
file update feature of the RMTGEN program. 


Listed below are the major parameters, with a brief descrip- 
tion ef each, which the user might consider altering as a 
function of hardware and software performance considerations. 


VARIABLE DESCRIPTION 


&DEBUG Conditionally assembles the RTP1130 internal 
core dump program (SSDUMP) and the BSC adapter 
trace routine (DBUGSCAL). Default value 
inhibits the assembly of these debugging 
programs. 


&CNPSIZE Maximum console printer message size. Default 
value is 120 bytes per message. 


&CONINSZ Maximum console keyboard input buffer size. 
Default value is 120 characters per command. 


&PRFOTKL Number of 1403 printer buffers (tanks) provided 
at assembly time. Default value is 2. The 
TPGET processor will build up to the value of 
&PRFOTKL and then suspend operation for the 1403 
until the count of buffers falls below &PRFOTKL 
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VARIABLE 


&PRETTKL 


& PUNFTKL 


&CONSTKL 


&PRFOBFL 


&PRETBFL 


& PUNFBFL 


&CNSPBFL 


&NPTFBFL 


DESCRIPTION 


Number of 1132 printer buffers (tanks) provided 
at assembly time. Default value is 2. See 
&PRFOTKL for TPGET action. 


Number of 1442 punch buffers (tanks) provided 
at assembly time. Default value is 2. See 
&PRFOTKL for TPGET action. 


Number of console printer buffers (tanks) pro- 
vided at assembly time. Default value is 5. 
See &PRFOTKL for TPGET action. 


Maximum number of TP buffers containing data 
destined for the 1403 printer which will be 
accepted by TPIOX before setting the trans- 
Mission suspension bit defined in the FCS for 
the 1403. HASP will suspend transmission of 
1403 print data until the FCS bit is reset 

when the number of 1403 TP buffers becomes 

less than the value of &PRFOBFL. Default value 
is 2. 


Same definition as &PRFOBFL except it applies 
to the 1132 printer. Default value is 2. 


Same definition as &PRFOBFL except it applies 
to the 1442 punch. Default value is 2. 


Same definition as &PRFOBFL except it applies 
to the console printer. Default value is l.. 


Maximum number of TP buffers allotted to input 
devices collecting data to be sent to HASP. 
Default value is one greater than the number 
of card readers defined for RTP1130. 
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4.15 EXECUTION TASK MONITOR 





The Execution Task Monitor is a processor which periodically examines 
the CPU utilization of user tasks within a dynamic priority group and re- 
arranges the OS/ 360 task dispatching chain giving higher priority to those 
tasks, within the group, which use the least amount of CPU time. Tasks 
above and below the dynamic priority group are not affected by the rearrange- 
ment of the dispatching chain. Tasks with all of the following characteristics 
are included within the dynamic priority group: 

1. The task is a job step of a job scheduled by HASP. 
2. The current dispatching priority of the task is 
a. equal to priority of the dynamic group as specified by 
the value of the &XZPRTY parameter for MVT or 
bd. not greater than the value &XZMFTH and not less than the 
value of &XZMFTL for MFT. 
3. The job step i not multi-tasking. (The user does not ATTACH 
other tasks.) 

The interval between the periodic examinations is controlled by the value 
of the &MONINTV parameter. Setting &MONINTV value to a positive integer 
will cause the processor to be menetatad: OS/360 must support Job Step Timing 

and must not have a Time Slicing Group Defined at the priority level(s) 


corresponding to the priority range of the dynamic group. 
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4.15.2 Execution Task Monitor - Algorithm 


The Execution Task Monitor determines the CPU utilization history (ht_ p) 


for each task within the dynamic priority group using the following formula: 


he n=CPUy nthe-1 no H,/N 


I! 


where: Hy = cpu;y , thy) (itcpuy athe-j 2+. + -Cpuy, N*ht-1,N 


= Total CPU counts observed for the N tasks being 
monitored plus the sum of the previous history values. 
N = The number of tasks being monitored at the end of 
the time interval. 
h = The history of CPU utilization for task (n) during 
the current time interval. 
hy- 1 n The history of CPU utilization for task (n) taken at 
the previous time interval. 

New tasks, entering the monitored group, will be assigned a history 
value of zero and temporarily placed at the low priority end of the group. 
Task with continuous low values of CPU counts will have (h) values which 
become increasingly negative. The (h) values will be prevented from falling 
below the range of one time interval; thus providing responsiveness to 
erratic changes in the corresponding task's CPU utilization. 


Low values of h indicate the task (1) has not been able to utilize the 


CPU time given to it because of waiting for events such as I/O or (2) 
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has not been given the opportunity to utilize the CPU. High values of h 
indicate the task has had the opportunity and has utilized the CPU. The 
Execution Task Monitor performs a partial sort and rechains the monitored 
tasks, insuring that the task with the largest history of CPU utilization 
will have the lowest effective priority within the dynamic priority group 
during the next time interval. This will by default raise the effective 


priority of other tasks in the group. 
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4.16 INTERNAL READER : 


4.16.1 Internal Reader - General Description 


The Internal Reader Processor is an Input Service Processor which 
reads card images from any system or user task running under OS/360. 
The Internal Reader recognizes, through the use of Execution Control 
Processor interface routines, an attempt by other tasks running under OS/360 
to punch information into "cards" on pseudo 2520 punch devices, performs 
the function of the Input service Processor on each card, and via OS/360 


POST macro signals completion of I/O to the submitting task. 


4.16.2 Internal Reader - Program Logic 


The Internal Reader uses the code of the Input Service Processor with 
modifications in the following areas. 

1. Processor Initialization - The Internal Reader attempts to 
obtain an internal reader device control table (DCT) which 
contains an 80 byte buffer area rather than a normal 
reader DCT. When a device is received the processor 
continues by acquiring a direct-access DCT and passes 
control to the main processor. 

2. Main Processor - The Internal Reader RGET routine tests 


for the existance of a submitting task punch channel program. 


Internal Reader Processor — Page 4.16-1 


173 


HASP 


If no channel program exists the Processor will wait for 
WORK. If a channel program exists RGET will simulate the 
punching of one card into the 80 byte DCT buffer area (no 
data chaining). If the channel command represents the 
énd of the channel program RGET posts completion of I/O 
and resets channel program indicators. RGET returns to 
the main processor passing the card image for processing 
or in the event the "card" has "/*EOF" in columns 1 to 5 
returns indicating end of file. 

Processor Termination - Termination of the Internal Reader 
involves terminating the last job (if any), re-easing the 
direct-access and internal reader device DCT's, and passing 


control to the processor initialization routines. 


The Internal Reader requires supporting routines in the Execution Control 


Processor Asynchronous I/O Handler which perform the following functions: 


Ls 


Recoanize EXCP macro references to designated internal readers 
as setup by HASP initialization. 

Make the internal reader available éé the Input Senies peaeeceer 
on first use. 

Set up the first channel command word and IOB setae ‘ 

Force the submitting task in the wait state if required. 


Post the Input Service Processor for WORK. 
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4.17 | MULTI-LEAVING LINE MANAGER | 


4.17.1 MULTI-LEAVING Line Manager — General Description 


The function of this processor is to control all line activity with remote 
terminals. This includes line initiation/termination, remote terminal 


synchronization, line error recovery, and sign-on/sign-off processing. 


en ee ee 


- 
- ee a 


This processor interfaces very closely with the Remote Terminal Access 


Method described in section 5.15. 


4.17.2 MULTI-LEAVING Line Manager — Program Logic 


When this processor receives control from the dispatcher it first 
determines whether an I/O operation has completed. If not, it then scans 
each line (via the line Device Control Tables) to check for requested 
processing. When all processing has been completed the processor then 
returns control to the dispatcher (SWAIT's) until such time as more work 
becomes available. 

When a channel end is detected, the channel end routine determines 
the sequence type of the Channel Command Word chain and branches to the 
appropriate section to analyze the channel end and initiate any error 
recovery procedures required. 

The line Device Control Tables (DCT's) are scanned and when one is 


found to be available the Line Initiation routine is entered which acquires | ‘ 
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the DCT, acquires a TP buffer, constructs an initial CCW chain, and 
initiates V/o on the line. 
A single timer queue element is maintained by the Line Manager to 
initiate delays in line processing. This facility provides the capability 
of delaying a null response to a remote terminal and decreases the 
associated degradation. Various other timer queue elements are maintained 
by individual line processors to initiate other delays of varying intervals. 
The code in this processor is assembled conditionally such that only 


the instructions required to process a given configuration will be generated. 


MULTI-LEAVING Line Manager — Page 4.17-2 


196 


HAS P 


4.18 


—64.18.1 


4.18.2 


REMOTE CONSOLE PROCESSOR 


Remote Console Processor - General Description 


The function of this processor is to process all console 
messages to and from remote terminals. This routine 
optionally saves messages to remotes which are not “signed 
on" MULTI-LEAVING terminals for later printing on the 
remote terminal printer. 


Remote Console Processor - Program Logic 


This processor receives control whenever a console message 
is queued for a remote terminal or whenever a console mes- 
Sage is received from a remote terminal. The processor 
first examines the output queue of messages and upon en- 
countering a message queued for a remote terminal examines 
the current status of the terminal. If the terminal is 
not an active BSC MULTI-LEAVING terminal the message is 
purged (the console message buffer is returned to the 
available queue) or the message is saved on the SPOOLI1 
volume if operator message SPOOLING is requested. 


If the message is to be written, a Remote Console Device 
Control Table is constructed for the specific remote termi- 
nal, the DCT is chained onto the other DCTs for this 
remote, the DCT is "OPENed" by calling the Remote Terminal 
Access Method, all messages which are queued are written 

to the terminal, and the DCT is "CLOSEd" and unchained. 

If the message to be written is for a currently inactive 

or for a non-MULTI-LEAVING active remote and HASP operator 
message SPOOLING space is specified (&SPOLMSG # 0), an at- 
tempt to save the message on the SPOOL1 volume for later 
printing at the remote by printer support routines is made. 
The remote MESSAGE SPOOLING QUEUE (SMSPOOLQ) element for 
the designated remote is examined for a queue HEADER entry 
of zero. If zero, a record is allocated from the MESSAGE 
ALLOCATION (SMSALLOC) Table, and the corresponding MTTR for 
the record is placed in both HEADER and TRAILER entries 

for the remote. (Non-zero but equal HEADER and TRAILER 
entries signify that the queue exists; however, since the 
last record of each remote element is always empty no data 
is currently queued). A record is allocated from the 
SMSALLOC table to represent the new end of message queue 
and the associated MTTR is placed in the chain field of the 
current HASP buffer. The HASP buffer is then filled with 
the operator message and any more messages for the same 
remote currently queued and written on the SPOOL] volume | 
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at the record location designated by the TRAILER MTTR for 
the remote. Upon completion of I/O the chain field replaces 
the TRAILER MTTR. The above process is repeated for addi- 
tional buffers as required to empty the console message 
queue for the remote. 


In the process of allocating message records the S$MSALLOC 
table bit map is used. Each bit in the map when on repre- 
sents a free record on the SPOOL1 volume. Allocation con- 
sists of finding the highest numbered bit that is on, 
turning the bit off, and converting to a corresponding MTTR. 
When all bits in the map are off indicating that no records 
are available, the messages are purged. 


If an input message is to be read, a Remote Console Device 
Control Table is constructed and the Remote Terminal Access 
Method is utilized to "GET" the message. The message is 
written to the local console and then queued for the Command 
Processor. | 
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4.19 


4.19.1 


4.19.2 


EXECUTION THAW PROCESSOR ’ 
EXECUTION THAW PROCESSOR - GENERAL DESCRIPTION 


XTHAW iS a companion to the main Execution processor IOS 
interface routine called XFREEZE. XTHAW is responsible for 
discovering which tasks have been forcibly placed in an OS 
WAIT state by XFREEZE (frozen) and should now be activated 
(thawed) thru the OS POST ECB mechanism. 


EXECUTION THAW PROCESSOR - PROGRAM LOGIC 


XTHAW uses an IOB (HASP buffer) chain constructed thru the 
XTHAW PCE or the Execution Processor PCE(s) in the XPCEECB 
field of the PCE work area. The chain is constructed using 
the XTHAW or an Execution PCE depending on the reason for 
invoking XFREEZE. If the IOS interface section is entered 
while an Execution processor is active, then the XTHAW PCE 

is used. If an I/O request cannot be processed and an 
Execution processor is not active at the time of the request, 
then the PCE controlling the caller is used to build the 
chain. 


XTHAW is activated (SPOSTed) by the Execution Processor 
whenever a Job or the HASP controlled OS Reader/Interpreter 
is active and just prior to SWAITing for work. A special 
status bit (XPOSTBIT) in the XPCESTAT field of an Execution 
PCE is used as the primary test for processing the IOB chain. 
This bit is not turned on when the OS Reader/Interpreter 

is active and assigned to a PCE but does not have a job to 
process. This prevents unnecessary activation (thawing) of 
the Reader/Interpreter when no Jobs are available for initia- 
tion. 


XTHAW performs the following major functions: 


(1) Examines the XPCEECB field of the XTHAW processor. 

If this field is non-zero, it is used as the pointer 
to a chain of IOBs (HASPbiffers) which contain ECBs 
to be POSTed (thawed) and the HASP/OS POST subroutine 
(WPOSTECB) is used to perform the POST. The chain 
address for the IOBs is contained in the IOBCSW field 
which is set to zero for the last IOB. 

(2) Next, the Execution PCES are searched for the XPOSTBIT 
condition and the XPCEECB field is processed as de- 
scribed in Step 1,.if the XPOSTBIT is on. 

(3) XTHAW SWAITs for work after processing all PCEs as 

: described. 
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4.20 OVERLAY ROLL PROCESSOR 


4.20.1 Overlay Roll - General Description 


This Processor operates in conjunction with the Overlay Service 
Routines. Description of them in Section 5.16 should be read to 
provide proper background to understanding of Overlay Roll. MThe 
objective of this Processor is to prevent system lockout due to 
SWAITS in overlay routine coding. 


4.20.2 Overlay Roll - Program Logic 





This Processor's PCE is placed lowest on the HASP Dispatcher chain 
and it SWAITs on ABIT when idle. This means that all Processors 
with their requested overlay routine in an Overlay Area will have 
at least one chance to execute code or otherwise use their overlay 
routine before the Overlay Area containing that routine is taken 
for other use. Overlay Roll does not receive control unless all 
other HASP Processors are in a SWAIT state, i.e., HASP is ready 

to relinquish control to OS by WAIT. Overlay Roil always receives 
control, just before WAIT is executed. 


Overlay Roll has local addressability provided in BASE2 and also 
establishes the base address for Overlay Service in register WC so 
that its subroutines and tables may be used. On each entry, the 
Queue beginning with SWAITACE (see 5.16.2) of PCEsS waiting for an 
Overlay Area is tested. If empty, SWAIT ABIT is used to exit. 
Otherwise, the following attempts are made to secure one or more 
Overlay Areas and begin reading a requested routine into them. 


For each group of one or more waiting PCEsS requesting the same over-. 
lay routine, all Overlay Areas are searched to find a suitable one. 
If a read operation to load an overlay routine is in process, the 
area is never taken. Users of that routine are allowed at least 
one chance to execute after read completion is processed by Overlay 
SASYNC Exit (see 5.16.9). 


For each Overlay Area which does not have read in process, the 
OACEPRIO field is examined and the chain of all current users 
(beginning at OACEPCE) is searched to determine if any user is 
SWAITing on I/O. This would be I/O other than an overlay read 
operation, would be expected to complete "soon", and would, there- 
fore, make it less desirable to pre-empt that area. The lowest 
priority area with no user sWAITing I/O is chosen, if any, other- 
wise the lowest priority area is chosen. 


Since an overlay routine is ipefreshapie® at S$WAIT time, it is not 
necessary to literally "roll", i.e., write to disk, a pre-empted 
Overlay Area. Each PCE on the chain of current users (OACEPCE) is 
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processed to prevent further use of the pre-empted area by it. 

The re-entry address (PCER15) is “sized" to determine if it points 
into the Overlay Area and if so is relativized by subtracting the 
Overlay Area address. The PCE is forced into a SWAIT OROL state, 
in addition to the other S$WAIT conditions present. When other 
SWAIT conditions have been $POSTed, the Dispatcher (see 5.1.2) 
detects the PCE $WAITing OROL only and sets it to call on Overlay 
Service. OLOD subroutine (see 5.16.8) is eventually called to 
refresh the routine, either directly, or if the PCE gets into the 
SWAITACE Queue, by OEXIT subroutine (see 5.16.7) or by Overlay Roll. 


The area thus pre-empted is used to read in a new overlay routine, 
to be used by the highest priority PCE group on $WAITACE. The OLOD 
subroutine (see 5.16.8) is called to begin the read operation. 


If there are more PCE groups on the $WAITACE Queue, the above actions 
are repeated. When Overlay Roll finally exits by SWAIT ABIT, the 


SWAITACE Queue is either empty or all Overlay Areas have an overlay 
read operation started, to be posted by Overlay S$ASYNC Exit. 
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4.21 HASP SMB WRITER (HASPWIR) 


4.21.1 HASP SMB Writer - General Description 





The primary function of this program is to read System Message 
Blocks (SMBs) from the data set SYS1.SYSJOBQE and "print" them to 
HASP. The process signals the end of the OS execution phase of a 
job's processing and makes the messages (JCL, JCL diagnosis, allo- 
cation/disposition, SMF, etc.) available to HASP, to be later 
printed with print data sets of the job previously SPOOLed by HASP. 


This program is used as an attached task, in the HASP region or 
partition, if the HASPGEN parameter &WTRPART is set to "*",. Other- 
wise, the standard OS Output Writer is used to fulfill the same 
functions and is started by HASP in a separate partition, using a 
procedure named HOSWTR. The re-queuing feature described below is 
only available when using HASPWTR. 


The program HASPWTR depends upon OS Queue Management structures 
(OCR, LTH, SMB, no-work ECB) as documented in 0S/360 MVT Job 
Management PLM. Functions such as enqueue, dequerie or delete of 

a job; ENQ/DEQ to control access to Queve Management resources; and 
conversion of record addresses between NN, TTRO, and MBBCCHHR forms 
are all performed in a manner consistent with that described for 
the standard OS Job Management modules. 


Microfiche listings for IEFQDELO, IEFOMDQQ, and IEFSD086 were 
consulted as examples during the development of HASPWTR. However, 
no actual Job Management modules are executed by HASPWTR. 





4.21.2 HASP SMB Writer - Program Logic 


On initial entry after being ATTACHed, the program saves three 
addresses passed to it by HASP Initialization: memory address of 
the pseudo 1403 UCB designated by the HASPGEN parameter &WTR, 
address of a HASP subroutine to be called to signal end-of-job, 
and address of an ECB which will be posted by HASP if the operator 
enters the command $P HASP. After signalling HASP (via a POST) 
that ATTACH was successful and setting up addressability to the 

OS Queue Manager resident DCB and DEB for SYS1.SYSJOBQE, the pro- 
gram enters its major processing loop. 


The major processing loop is driven by inspection of a list of 
ECBs. One is the $P HASP ECB which, if posted, causes the program 
to terminate as described below. All other ECBs are each part of 
an eight byte no-work element. One such element is present for 
each SYSOUT (MSGCLASS) to be processed, as indicated by the list of 
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classes assigned to the HASPGEN parameter &WTRCLAS. If an ECB is 
posted, the Queue Control Record (QCR) for that class is read and 

a job is dequeued, if present. The dequeued job's last Logical 
Track Header (LTH) must be read to perform the dequeue. The updated 
QCR is re-written. If there were no jobs to dequeue or the one 
dequeued was the only one, the class ECB is cleared and the no-work 
element is chained from the QCR before re-writing. 


If a job was dequeued, its SMBS are read, messages are formatted 
into print lines, and the lines are "printed" to HASP using the 
pseudo 1403 UCB. If non-SMB blocks such as Data Set Blocks (DSBs) 
are encountered, they are simply skipped. The data sets they 
represent are not printed or scratched. When the end of the job 
is reached, a small subroutine in HASP is called to signal end-of- 
job to HASP. 


The HASPGEN parameter &WCLSREQ controls the disposition of the job 
after processing. If the position in the list &WCLSREQ, correspond- 
ing to the position of the job's original class in the list &WTRCLAS, 
is a valid SYSOUT class then the job is re-queued in the QCR for | 
that new class. Any tasks (e.g., other system writers for perhaps 
CRBE, CRJE, TSO, CPS, etc.) whose no-work elements are chained from 
that QCR are POSTed. The re-queue action always places the job in 
the new QCR chains at highest priority. 


If &WCLSREQ does not indicate re-queuing ("*" in a list position 
instead of a class), the job's tracks in SYS1.SYSJOBQE are released 
by chaining them to the chain of free space beginning in the Master 
QCR, POSTing any tasks waiting for Job Queue space, and re-writing 
the Master QCR. | 


The major processing loop is repeated until no ECBs are found posted. 
An OS multiple WAIT is executed and when any ECB is posted by another 
task (usually an OS Job Terminator), the major processing loop is 
resumed. 


If the operator enters $P HASP, HASP will POST an ECB to signal 
termination actions to this program. All QCRs for processed classes 
(SWTRCLAS) are read, the no-work chain of each is zeroed, then the 
QCR is re-written. HASPWTR exits with a zero completion code. 


If permanent I/O errors occur during any I/O on the SYS1.SYSJOBQE 
data set, an error message is always written to the operator. For 
write operations, no further special action is taken and processing 
continues. For read operations, an attempt is made to minimize 
system damage. No input from an incorrect read is ever used for 
processing. If the error occurs in reading a QCR or LTH while 
attempting to de-queue a job, the ECB is set so that no further pro- 
cessing of that class will be attempted. If there is an SMB read 
error, end-of-job is signalled to HASP and no further blocks on that 
job's chain are read. If a QCR read error occurs during a re-queue 
attempt, the job is deleted (tracks are released). 
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4.22 PRIORITY AGING PROCESSOR 


4.22.1 Priority Aging Processor -- General Description 





The function of the Priority Aging Processor is to regularly 
increase the priority of a job in such a way that its position 
in the HASP Job Queue is enhanced with the passage of time. 
This is accomplished by regularly passing through the HASP Job 
Queue and incrementing the priority field of all Job Queue 
Elements whose priority falls between upper and lower limits. 
These limits, as well as the time interval, are HASPGEN 
parameters and can be specified to fit the needs of an 
installation. 


4.22.2 Priority Aging Processor -- Program Logic 





When this processor is dispatched, it searches through the HASP 
Job Queue until it encounters a Job Queue Element whose priority 
field "QUEPRIO" (see figure 8.6.1) is less than the HASPGEN 
parameter: &PRIHIGH. For that Job Queue Element and every Job 
Queue Element after that (until the HASPGEN parameter &PRILOW 

is reached), the priority field is incremented by one. The 
Interval Timer is then reset and the processor enters a HASP 
SWAIT until the timer interval expires. 


Since the priority of the Job Queue Element is represented by 
the four high-order bits of "QUEPRIO", adding one to this field 
has no immediate effect on the priority. After repeating this 
operation sixteen times, however, the actual value of the 
priority will be increased by one. The value of the time 
interval is actually only one-sixteenth of the interval implied 
by the HASPGEN parameter: &PRIRATE. This effect tends to smooth 
out the process of priority aging by creating less impact when 
an interval expires. 


In order to minimize CPU utilization, this processor discontinues 
operation whenever the HASP Job Queue is empty and does not 
continue until a new job enters the system. 
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4.23 SYSTEM/3 REMOTE TERMINAL PROCESSOR PROGRAM LOGIC 


The HASP System/3 Remote Terminal Program is assembled on a 
System/360 or System/370 computer under OS, using Assembler F 
(IEUASM). The advantages of assembling under OS are: the 
System/3 program can be assembled as part of a standard HASPGEN 

or RMTGEN; a System/3 program can be customized to the particular 
System/3 configuration and HASP System being generated, since 
Assembler F can handle conditional assembly statements; and macros 
can be used. 


To allow assembly of System/3 code, a set of macros is included 
as part of the System/3 source code, HRTPSYS3. Most of these 
macros are designed to generate machine language code for the 
System/3; a few additional macros, such as S$WAIT and SFB, provide 
for in-line functions and control blocks. The former macros will 
be discussed first; they are called the machine-language macros. 


The machine-language macros consist of a set of macros whose names 
correspond to the mnemonic System/3 operation codes defined in the 
publication "Card and Disk System Components Reference Manual" 
(Order Number GA21-9103) and the extended System/3 assembler 
mnemonics defined in the publication "Disk System Basic Assembler 
Program Reference Manual" (Order Number SC21-7509), with the fol- 
lowing exceptions: each mnemonic operation code is prefixed by a 

dollar sign; no macros are provided for the instructions ZAZ, AZ, 
and SZ; additional extended mnemonics S$NOPB and S$NOPJ are provided; 
and the form and order of the operands is such as to be convenient 
to Assembler F. 


When a machine-~language macro refers to a location in core, the 
operand is coded either "address" or "(displacement,register)". 
Thus one might write "SMVC X'1234', (0,REG2) ,LENGTH" to move LENGTH 
bytes to core location X'1234' (and succeeding lower-addressed 
bytes) from the core location pointed to by REG2 (and succeeding 
lower-addressed bytes). 


There are ten forms of machine-language outer macros. These are: 


i The two-address form exemplified by "SMVC adrl,adr2,length". 
The operands "adrl" and "adr2" are as explained above. The 
operand "length" is assembled as "length-1l" unless it is 
omitted or is literally "*-*" (in which case it is assembled 
as zero) or the opcode is SMVX, in which case it is assembled 
as "length". The opcodes SMVC, S$ALC, SED, SITC, SCLC, and 
SMVX belong to this form. The extended mnemonics $MZZ, SMZN, 
SMNZ, and SMNN may be used. 


2% The one-address form exemplified by "SL reg,adr" and including 
SL, SA, SLA, and SST. 


35 The one-address form exemplified by "S$MVI adr,immediate" and 
including SMVI, SCLI, SSBN, SSBF, STBN, and STBF. 
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4, The Jump instruction, written as either "S$JC adr,cc" or 
"SJxxx adr", where SJxxx is one of the extended mnemonics. 
In this case, "adr" may not be specified as 
"(displacement,register)" and must be within a positive dis- 
placement of 256 bytes from the last byte of the Jump 
instruction. 


5. The Branch instruction, written as either "SBC adr,cc" or 
"SBxxx adr" where SBxxx is one of the extended mnemonics. 


6. The one-address I/O forms, exemplified by "SLIO da,m,n,adr" 
and including $LIO, STIO, and $SNS. 

Ts The instruction $SIO, written as "SSIO da,m,n,cc". 

8. The instruction SAPL, written as "SAPL da,m,n". 

9% The instruction SHPL, written as "SHPL cc", where each "c" 


is either the actual character to be displayed as a halt code 
or the character "*", indicating a byte of zeros. For exam- 
ple, one might write "SHPL EJ". 


10. The assembler instructions $DC and SDS, where the statement 
label (if any) is assigned the address of the last byte of 
the last operand specified. 


In addition to the machine-language macros, a S$USING and a S$DROP 
macro are provided to enable Assembler F DSECTs to be used more 
easily. The form of the SUSING macro is "SUSING expression,reg- 
ister" where "expression" is a one-to-eight-character expression 
with the location counter reference symbol "*" either not used or 
used as the first character, and "register" is a one-to-eight- 
character absolute expression. No more than two different 
SUSINGs (two SUSINGs with different arguments "register") may be 
outstanding at any time. SUSING works as follows: from the time 
the SUSING is issued, for any address-type machine-language macro 
which contains an address specification of "(displ,reg)", the 
character string "reg" is compared with the string "register" of 
each outstanding SUSING. If no match is found, the displacement 
is assembled as YL1(displ). If a match is found, the displacement 
is assembled as YL1(displ-(expression)), where "expression" is 
taken from the corresponding SUSING. 


The form of SDROP is "SDROP register" where "register" is a char- 
acter string that appeared as the second operand of a previous 
and outstanding SUSING. The form "SDROP register,register" is 
also allowable. 


The assembly listing generated by Assembler F contains the macro- 
expansion for each macro used, in order to provide a printed copy 
of the generated text of each machine instruction and the address 
at which it will be loaded in System/3 storage. The expansion 

of each of the machine-instruction macros is typically contained 

in one print line, and the text of the generated instruction is 
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always contained in hexadecimal on one print line. 

The object deck produced by Assembler F is used as input to the 
translation program SYS3CNVT, called automatically by RMTGEN. 
SYS3CNVT reads the object deck via either ddname SYSLIN, or 
ddname SYSGO if SYSLIN is absent. First, SYS3CNVT punches on 
SYSPUNCH a System/3 one-card loader. Then it reads from SYSLIN 
or SYSGO, ignoring all but TXT cards and the END card. For each 
TXT card, SYS3CNVT creates one System/3 96-column load-mode card 
image, Suitable for reading by the System/3 one-card loader. Each 
such 96-column card image contains 64 bytes of information as 
follows: 


® bytes 1-5 contain a System/3 SMVC instruction of the form 
"SMVC load-adr, (column-number,1),length-1" where load-adr 
is the absolute load address of the rightmost byte of text 
on the corresponding 80-column Assembler: F object deck TXT 
card, column-number is the number minus one of the 96-card 
column in which appear the low-order six bits of the right- 
most byte of text, the digit "1" refers to the System/3's 
register 1, and length is the number of bytes of text on 


the card; 

@ bytes 6-61 contain a maximum of 56 bytes of text, starting 
in column 6; and 

@ bytes 62-64 contain a three-digit card sequence number. 


When the object deck's END card is detected, or when a TXT card 
appears that was generated by the SEND macro (whose optional key- 
word operand START= specifies the starting execution address of 

a segment of text), a 96-column load-mode card image is constructed 
whose 64 bytes are as follows: 


® bytes 1-4 contain a System/3 $B instruction of the form "SB 
address" where address is either the first byte of the text 
segment just loaded (if the SEND macro does not specify 
START=, or if the END card of the assembly has no operand) or 
the address specified in the START= parameter of the SEND 
macro or the operand field of the END card; 

@ bytes 62-64 contain a three-digit card sequence number. 


After the object deck's END card has been processed, SYS3CNVT 
creates a 96-column card image of which columns 2-4 are "EOR" 
(this is the rep terminator card, End-of-reps) and columns 62-64 
contain a three-digit card sequence number. 


Certain of these 96-column card images contain descriptive infor- 
mation in bytes 33-64: these are the one-card loader, which is 
captioned "FIRST CARD"; the card created from a SEND macro, which 
is captioned "PSEUDO-END"; and the card created from an END card, 
which is captioned "LAST CARD". — 


After it has created each 96-column card image (including that for 


the one-card loader), SYS3CNVT breaks the image in half and punches 
two 80-column cards from it. Each 80-column card punched by 
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SYS3CNVT contains the following fields: 


© columns 1-2 are blank; | 

@ columns 3-50 contain the first (if column 80 is odd) or the 
last (if column 80 is even) 48 bytes of a System/3 card 
image; : | 

© columns 51-72 are blank; 

) column 73 contains the punch combination for X'80', an 


indicator to any System/3 Remote Terminal Program generated 
with &S396COL=1 that two 80-column cards are to be combined 
and punched as one 96-column card (the System/3 Starter System 
is generated with &S396COL=1) ; 

e columns 74-80 contain the remote terminal identifier and card 
sequence number, in the form "Rmmnnnn", where nnnn is 0001 on 
the first card punched. 


The punched output of SYS3CNVT may be routed directly to a System/3 
which is running the Starter System or other suitable System/3 Re- 
mote Terminal Program; the resulting 96-column punched deck of 
cards is immediately ready for loading into a System/3 of the 
proper configuration. Alternatively, SYS3CNVT's punched output 

may be punched on 80-column cards for later transmittal to a 
System/3. Each 80-column card is suitable for data transmission .: 
in either transparent or non-transparent mode. 


ae 
- wo 
at 
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The following pages constitute the Program Logic manual for the 
System/3 Remote Terminal program. 


The program consists of processors, interrupt routines, and system 
subroutines. There is a processor for each logical function to 
be performed by the program; each processor is controlled by a 
Function Block (somewhat analogous to a TCB in OS). Interrupt 
routines are provided for those devices (BSCA, 5471, and 5475) 
which are capable of interrupting the CPU; other devices are 
operated by processors. For example, the MFCU processor operates 
a hopper of the 5424 MFCU; it becomes associated with either a 
logical reader processor or a logical punch processor, depending 
upon the state of the hopper. 


The various routines of the System/3 Remote Terminal program 
are described in the order in which they appear in the listing. 
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IHEREP - HASP Environmental Recording and Error Processor 


IHEREP prints at program load time the error statistics gathered 
from the previous running of the System/3 Remote Terminal pro- 
gram. IHEREP is then overlaid and the Remote Terminal program 
continues to load. | | 


First, IHEREP loads the 5203 forms length register and selects 
the correct print chain image according to the printer's status 
information. Then it checks the log area for validity. If the 
log area is valid, the characters 'HASP' will appear immediately 
before the log area. If these characters do not appear, IHEREP 
prints the message 


HEREP COUNTERS HAVE BEEN ALTERED 
and branches to zero to cause program loading to resume. 


If the log area is intact, it contains eight two-byte counters 

for each status byte which can contain unit check information 

for a device. IHEREP prints a title line and then, for each 

status byte, a subtitle line and as many as eight detail lines. 

A subtitle line contains device description and status byte rfumber. 
A detail line contains status bit description, bit number, and 
count of bit occurrences in decimal. 


Control of IHEREP resides in the table of subtitles and detail 
descriptors, and control of the two-byte bit counters is by a 
bit string (starting at symbol IHBIT1) containing one-bits 

for the counters to which correspond detail descriptors. The 
table of subtitles and detail descriptors is made up of SIHMSG 
macros; if the first operand of this macro is 'T', the macro 
defines a subtitle, and if the first operand is an integer 
between 0 and 7, it specifies a detail descriptor for the bit 
whose bit number is the first operand. The table entries are 
used in order, and a byte of zero defines the end of the table. 


When the HASP Environmental Recording and Error Printout is com- 
plete, the counters are zeroed out and IHEREP branches to zero 
to continue program loading. 
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SCOM - Commutator 


The Commutator gives control in turn to the various processors 
which comprise the System/3 Remote Terminal program, based upon 
the status of the various Function Blocks (FBs). 


If the Event Wait Field (FBEWF) of an FB has zeroes in the bit 
positions defined by EWFALL, the function is said to be dispatchable. 
$COM loads register one from field FBREG1 of the FB (register two 
points to the FB) and gives control to the associated processor by 
loading the Instruction Address Register (IAR) from field FBENT. 


When the processor has completed its work, it returns to the com- 
mutator with register two pointing to its FB. It may return to 
SCOMRET, where $COM will save both the Address Recall Register (ARR) 
as the processor's next entry point and the value of register one; 
SCOMRETA, where $COM will save the value of register one; or 
SCOMRETB, where $COM will assume that both the value FBENT and 

the value FBREGI1 are correct. 


Then $COM chains to the next FB (or starts again with the first 
FB if the chain field FBNEXT is zero) and repeats the above process. 


< 
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SMFCU - 5424 MFCU Processor 


SMFCU operates under two FBs and two Hopper Control Areas (HCAs) - 
one for each MFCU hopper. The rovtine contains four levels of 
subroutines. 


SMFCU begins by calling first-level subroutine HREAD to read a 
card. HREAD sets up a read $SIO instruction from information 

in the HCA and calls second-level subroutine HEXCP. HEXCP calls 
fourth-level subroutine HTIO, which returns condition code equal 
if the hopper described by the HCA is ready and condition code 
unequal if it is not. If condition code unequal is returned, 
HEXCP returns to the commutator; it will regain control again at 
the call to HTIO. 


If the hopper is ready, HEXCP calls third-level subroutine HSIO 
to perform I/O on the hopper. HSIO first checks for various 
exceptional conditions. If error recovery is in progress (for 
the other hopper), HSIO returns immediately with condition code 
unequal. It returns similarly if the MFCU is busy reading, 
printing, or punching. If error recovery is not in progress and 
the MFCU is not busy, HSIO tests the "hurry" switch (which is set 
if one hopper is active and the other hopper becomes ready with 

a read SSIO pending for it). If the hurry switch is set and the 
current S$SIO is not a read-only $SIO, HSIO returns condition code 
false. 


If all the above tests are passed, HSIO checks the stacker request 
associated with the current $SIO. If the stacker request is dif- 
ferent from that for the previous $SIO, the feed path is checked 
to make sure it is clear. If the feed path is not clear, HSIO 
returns condition false; in addition, if the $SIO is read-only, 

it sets the "hurry" switch. But if the feed path is clear, HSIO 
resets the hurry switch, sets the new stacker number, and proceeds 
as if the stacker request for the current $SIO were the same as 
that for the previous SSIO. 


If no stacker change is indicated, HSIO moves the current SSIO 

to an in-line position from the HCA and examines it. If the S$SIO 
indicates print (interpreting), HSIO attempts to select one of two 
print buffers into which to move the punch information for the 
SSIO. If unsuccessful, HSIO returns condition code unequal. But 
if one of the print buffers is free (as indicated by the MFCU 
print-buffer-busy status bits) HSIO copies the punch data into 
the print buffer and modifies the SSIO instruction to indicate 
the print buffer being used. Then, or if the $SIO is read-only, 
HSIO loads the MFCU's read and punch data address registers. 
After a call to HTIO to insure that the hopper is still ready, 
HSIO issues the $SIO instruction, sets condition code equal, and 
returns to its caller, HEXCP. 
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HEXCP examines the condition code returned to it. If the condition 
code is unequal, HEXCP non-process exits, exactly as it did for 
HTIO above. But if the condition code is equal, HEXCP non-process 
exits to be entered again at a STIO which continues to non-process 
exit until the MFCU ceases being busy; then HEXCP calls third-level 
subroutine HSNS to determine the completion of the I/O operation. 


HSNS calls HTIO to see if a unit check condition exists. If that 

is the case, HSNS reads the MFCU status bytes. If all status bits 
in the error status byte are off (or if no unit check condition 
existed) HSNS returns condition code equal; if only the no-op status 
bit is on, HSNS returns condition code unequal. 


If other error status bits are on, HSNS calls system subroutines 
SMSG and $LOG to add a message to the error trace table and to 
count the error bits for HEREP, respectively. Then HSNS checks 
the error bits further. If the only error bits on are punch 
invalid or print check, HSNS returns condition code equal; these 
are regarded as user data errors (punch pnivanee! or trivial errors 
(print check). 


But if other error bits are on, HSNS sets the error-recovery-in- 
progress flag in HSIO (to prevent other $SIO instructions from 
resetting the error bits) and non-process exits until a SNS in- 
struction shows that all error bits (except no-op) have been reset 
by the operator (who must do a non-process run-out on the MFCU). 
Then HSNS returns condition code unequal. 


HEXCP returns to its caller (which was HREAD in this case) the 
condition code it received from HSNS. 


HREAD examines the condition code returned to it by HEXCP. If. 
unequal was returned, HREAD again calls HEXCP; otherwise first- 
level subroutine HREAD returns control to mainline $MFCU (in 
this case, at its second instruction). 


Having read the first card from its hopper, SMFCU now tests that 
card for blanks, via first-level subroutine HBLANK. If the card 
is blank, the hopper is assumed to contain blank cards to be 
punched. Otherwise, the hopper is assumed to contain a job 
stream and the MFCU awaiting-read routine HAR attempts to asso- 
Ciate the hopper with a free logical reader FB, using subroutine 
HGET. HGET returns condition code equal if it succeeds (it also 
posts the logical reader's FB for UNIT), and condition code 
unequal if the hopper becomes not ready (and therefore dormant 
rather than awaiting-read); otherwise, HGET non-process exits 
until one of the above two conditions happens. 


If HGET returns condition code equal, the MFCU reading routine, 


HRD, Signals to the now=-associated logical reader that the read 
buffer for the associated hopper is busy; then HRD non-process 
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exits until the logical reader frees the read buffer. When the 
read buffer is free, HRD checks the EOF flag, set by the logical! 
reader when it encounters a /*EOF control card. If the EOF fla; 
is on, HRD makes the hopper dormant by branching to the first 
instruction of S$MFCU; otherwise HRD calls first-level subroutine 
HREAD as above to read the next card and, on return, again sets 
the read buffer busy. 


If on the other hand SMFCU finds a blank card in a dormant hopper 
it gives control to HAP, the awaiting-punch routine, which tries 
to find (via HGET) a logical punch FB of which HASP has requested 
permission to send a punch stream. Having found such a logical 
punch, HAP gives control to HPU, the MFCU punch routine. | 


HPU non-process exits until the associated logical punch processor 
sets either the EOF flag or the punch-buffer-busy flag in the 

flag byte of its hopper control area. If the EOF flag is set, 

HPU makes the hopper dormant. 


But if the punch-buffer-busy flag is set, HPU punches and prints 
a card and reads the next card (to insure that only blank cards 
are punched). HPU sets up a read-punch-print S$SIO and calls 
second-level subroutine HEXCP. If HEXCP returns condition code 
unequal and the MFCU status indicates any of the errors no-op, 
punch check, hopper check, or feed check, the punch buffer is not 
marked free; otherwise it is marked free and set to blanks. The 
MFCU status is checked again; if neither read check nor no-op is 
indicated, the card is examined to determine if it is completely 
blank. Otherwise, or if the card now in the wait station is not 
blank, another card is read (via subroutine HREAD). When a blank 
card has been read successfully, HPU again checks for punch- 
buffer-busy as above. 
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$1442 - 1442 Card Reader - Punch Processor 


The $1442 processor is assembled if RMTGEN parameter &S31442 has 
been set to l. Its logic is similar to that of $SMFCU but simpler, 
Since only one hopper need be controlled. $1442 uses some of the 
subroutines of SMFCU; for this reason, and since its interface to 
the logical reader and logical punch is the same, the 1442 hopper 
control area is similar to (but not identical with) the HCAs of 
the MFCU. 


$1442 starts by reading a card from the 1442 via entry point 

GSIORD of subroutine GSIO. If the card is blank, GAP (awaiting- 
punch) calls HGET just as does HAP in SMFCU; if the card is non- 
blank, GAR (awaiting-read) calls HGET just as does HAR in $SMFCU. 


When a logical reader or logical punch has been associated with 
the 1442, GRD or GPU gains control and proceeds with I/O as indi- 
cated by the read-buffer-busy and punch-buffer-busy flags. In 
addition to recognizing the EOF flag set by the logical reader, 
GRD also recognizes the last-card status bit from the 1442 and 
sets the last-card flag, recognized by the logical reader. 


Subroutine GSIO performs I/O on the 1442. Entry point GSIORU 

sets a feed command in the SSIO and branches to common code. Entry 
point GSIORD sets a read-EBCDIC command in the SSIO and loads the 
data address register; it branches to common code. Entry point 
GSIOPU sets up a punch-and-feed command, loads the data address 
register and the punch count register, and falls through to 

common code. 


GSIO's common code non-process exits on a STIO until the hopper 
is ready. Then it issues the constructed SSIO and non-process 
exits until the 1442 is not busy. If entry was from GSIORU, 
GSTO returns condition code equal; otherwise it tests for unit 
check (via subroutine HTIO) and reads the 1442 status bytes. If 
no unit check occurred, GSIO returns condition code equal. 


But if the 1442 nad a unit check or otherwise became not ready, 
GSIO uses subroutines SMSG and SLOG to add a message to the 
error trace table and to count the error bits for HEREP, 
respectively; then it checks the status bytes. If no error bit 
is on, GSIO returns condition code equal; otherwise GSIO returns 
condition code unequal. 


net 
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$5203 - 5203 Printer Processor 


The 5203 Printer Processor non-process exits until another 
processor has marked the printer data area busy. Then it con- 
pletes the Q-byte and CC-byte of a $SIO instruction from an 
SRCB furnished it by either $PRINTER or $CONP. After a $TIO 
shows that the 5203 is ready, $5203 loads the printer image 
address register and the printer data address register and 
issues the $SIO. $5203 then non-process exits until the printe: 
is not busy. 


When the printer operation has ended, $5203 checks for errors. 
If any of the error incrementer failure check, hammer echo 
check, or any hammer on check has occurred, $5203 attempts to 
reprint the line. Otherwise it clears the print line to blanks, 
shows the print buffer free, and again non-process exits until 
a processor sets the print buffer busy. 


Additionally, whenever a unit check occurs, $5203 calls sub- 
routines $MSG and $LOG to produce an error message and to 
count the one-~bits in the printer status bytes. 
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SREADER - Logical Reader Processor 


SREADER waits for one of the physical reader routines to post it 
for UNIT. When posted, it sends to HASP a request-permission 
control sequence (via subroutine $REQ) and waits to be posted for 
PERM by. SBSCA when the system receives from HASP the appropriate 
permission-granted sequence. 


When it has received permission, SREADER non-process exits unless 
the read-buffer-busy flag is on, indicating a card is ready to be 
processed. Then it examines the card. If the card's columns 1-5 
are "/*EOF", SREADER sends to HASP an end-of-file control sequence 
(via subroutine SLEOF), which is merely a zero-length record. It 
then waits again for UNIT, and continues as above when posted. 

The same end-of-file processing occurs if the reader is a 1442 and 
the last-card flag was set by the 1442 physical reader routine. 
1442 code is absent unless &S31442=1. 


If there is no end-of-file indication, SREADER processes the card 
further. If object deck processing was not specified at RMTGEN 
time, $S$READER transmits the first 80 columns of the card to HASP 
by calling subroutine SCMPR. On return, SREADER resets the read- 
buffer-busy flag of the appropriate hopper control area and non- 
process exits until the read-buffer-busy flag is again set by the 
physical reader routine. Then it continues as above. 


However, if object deck processing was indicated at RMTGEN time by 
the specification &S30BJDK=1 and if the physical reader device is a 
5424, SREADER first checks column 81 of the 96-column card image 
for the character "1". If -the comparison is unequal, SREADER 
processes the card normally, as above. But if column 81 equals 
"1", the card is the first card of a two-card hexadecimal image of 
a full-EBCDIC 80-column card. In this case, SREADER compresses 

the first 80 columns of the card into the first 40 bytes of the 
same device's punch buffer, shows the read buffer free, and non- 
process exits until the read buffer is again busy. Then it checks 
the new card image for a "2" in column 81. If column 81 does not 
contain a "2", SREADER treats the newly-read card as a normal card, 
and the previous card is lost. If the new card contains a "2" in 
column 81, SREADER compresses its first 80 columns to the second 

40 bytes of the same device's punch buffer and transmits the con- 
structed card image to HASP, using subroutine S$CMPR. Then it 
resets the read-buffer-busy bit and non-process exits as above. 


Subroutine RDSQUEZE performs the above-mentioned compression. It 
creates a single sink byte from a pair of source bytes each of 

which is assumed, without validity-checking, to contain the 

EBCDIC representation of one of the sixteen hexadecimal characters. 
For example, it would compress the byte pair "FOC6" to the byte "OF". 
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SPRINTER - Logical Printer Processor 


SPRINTER waits for HASP to send a request-permission control 
sequence. When $BSCA finds such a sequence, it posts $PRINTER 

for permission. S$PRINTER then checks the printer availability 
Flag. It non-process exits until this flag becomes zero; then it 
sets this same flag to show that the printer is in use. It sends 
a permission-granted control record to HASP (via subroutine $PERM) 
and then, if the print buffer is free, calls subroutine $DCOM to © 
request a print line be decompressed into the print buffer. 


On return from $DCOM, SPRINTER recognizes two or three conditions: 
normal return, end-of-file return, and (optionally) forms mount 
message. 


For the forms mount message case, the SRCB (carriage-control byte, 
in the case of print records) will be X'8E'. SPRINTER makes the 
Carriage control byte a print-and-space-three, shows the print 
buffer busy, and non-process exits until the print buffer becomes 
free; then it sets a carriage-control byte of space-three-immediate 
(so that the forms mount message will be visible on the printer 
without operator intervention) and continues as in the normal case. 
This code is assembled only if &$35471=0. | 


For the normal-return case, SPRINTER moves the SRCB returned by 
¢DCOM to the printer control area as the carriage control byte, 
sets the print-buffer-busy bit, and non-process exits until the 
print-buffer-busy bit is off. Then it again calls $DCOM for the 
next print line. 


For the end-of-file case, SPRINTER resets the printer availability 
flag and checks to see if HASP had again sent a request-permission. 
If so, SPRINTER again sets the printer availability flag, sends to 
HASP permission-granted (via subroutine SPERM) and continues as 
above. Otherwise SPRINTER waits for HASP to send request-permission. 


em/3 Ren 
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SPUNCH - Logical Punch Processor 


SPUNCH waits for HASP to send a request-permission control sequence. 
When $BSCA finds such a sequence, it posts $PUNCH for PERM, where- 
upon $PUNCH waits for UNIT. When posted for UNIT by a physical 
device routine, $PUNCH sends a permission-granted control record 

to HASP (via subroutine $PERM) and non-process exits until the 
appropriate punch buffer is free. Then it calls subroutine $DCOM 

to decompress a card image into the punch buffer. 


If $DCOM returned a card image (rather than end-of-file) the image 
is processed in various ways, depending upon the type of the punch 
device and options selected at RMTGEN time. If the punch is a 
1442, S$PUNCH calculates the number of bytes to punch, subtracts it 
from 128, places the difference in the 1442 hopper control area, 
and shows the punch buffer busy. It then non-process exits, as 
above, until the punch buffer becomes free. 


If the device is a 5424, SPUNCH first checks column 1 of the card 
image. 


If column 1 is X'6A', the card image is assumed to be a HASP job 
Separator card. $PUNCH extracts the job number from columns 52, 
62 and 72, ignores the rest of the image, and punches a card of 

which columns 1-32 are: 


REEKKKKEKREK JOB nnn REEKKKKKEKKE 


It causes this card to be punched as usual, that is, by marking the 
punch buffer busy; then it non-process exits until the punch buffer 
becomes free. | 


If the device is a 5424 and RMTGEN specified &S396COL=1, SPUNCH 
checks column 73 of the card image. If that column is X'80',. 
SPUNCH checks column 80. If column 80 is odd, S$PUNCH saves ina 
work area in its Function Block the 48 columns starting at column 
3 and again calls $DCOM to get the next card, as above. If column 
80 is even, SPUNCH moves columns 3-50 of the card image to columns 
49-96, moves the first 48 bytes from its work area to columns 1-48, 
and causes the card to be punched. 


If the device is a 5424 and RMTGEN specified &S30BJDK=1, S$PUNCH 
checks column 1. If that column is X'02', SPUNCH saves the 
rightmost 40 columns of the 80-column card image in its work area 
and expands the leftmost 40 columns to 80 columns by substituting 
for each byte two EBCDIC characters; for example X'02' becomes 
C'02'. It sets the character "1" in column 81 and causes the card 
to be punched. S$PUNCH then repeats this process for the saved 40 
columns, sets the character "2" in column 81, and causes the card. 
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to be punched. 


If none of the above situations apply, SPUNCH merely marks the 
punch buffer busy, non-process exits until it becomes free again, 
and then calls $DCOM to get the next card. 


SDCOM may return an end<-of~file indication rather than a card 

image. $PUNCH sets the end-of<-file flag in the hopper control 
area and checks for a subsequent request-permission from HASP. 
If HASP has requested permission again, $PUNCH waits again for 


UNIT, as above; otherwise S$PUNCH waits for PERM, as above. 
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5471 Console Interrupt Routine 


CINT, the 5471 console interrupt routine, gains control upon an 
interrupt from either the 5471 printer or the 5471 keyboard. A 
keyboard interrupt may occur due to the End key, the Return key, 
the Cancel key, the Request key, or a Data key. A printer inter- 
rupt may occur either after completion of printing a character or 
after a carriage return. | 


At an End key interrupt CINT starts a carriage return, posts the 
console processor, and exits by starting the keyboard. If a 
request is pending, the Start-I/O instruction sets the request 
light on and disables interrupts from all keys; otherwise it sets 
both lights off and enables interrupts from the request key. 


A Return key interrupt causes the same functions as an End key 
interrupt. 


A Cancel key interrupt causes CINT to print an asterisk and set a 
flag which will cause a carriage return at the next printer inter- 
rupt. CINT then resets the buffer pointer to point to the first 
byte of the buffer and exits by issuing a SIO which leaves the 
same lights on and interrupts enabled as before the interrupt. 


At a Request key interrupt, CINT posts the console processor if 
an inspection of the console status byte CCFLG shows that neither 
input nor output is currently in process. In any case, it sets 
the request-pending bit and exits by issuing a SIO which turns on 
the request-pending light, disables request key interrupts, and 
leaves the proceed light and. other key interrupt indicators as 
they were before the interrupt. 


For a Data key interrupt, CINT saves the keyed character in the 
buffer byte pointed to by the buffer pointer; then it increments 

the buffer pointer by one. It issues a SIO to the printer so that 
the keyed character will be printed. If the buffer pointer now 
falls outside the buffer, CINT turns on the carriage-return request 
bit and performs ail the functions of the End key except for issuing 
a carriage return. Otherwise it exits by issuing to the keyboard a 
SIO which leaves the same lights on and interrupts enabled as 

before the interrupt. 


On a printer interrupt due to end of either printing or carriage 
return, CINT tests the carriage return request bit. If that bit 
is on, CINT resets it and exits by issuing a SIO for carriage 
return. | 


If there is no carriage return request pending, CINT tests the out- 
put-in-process bit. If output is not in process, CINT exits by 
disabling printer interrupts. But if output is in process, CINT 
checks whether the final output character has been printed. If so 
it resets the output-in-process flag, posts the console processor, 
and exits by starting a carriage return. If not, it selects and 
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loads ehe next character to print and exits By issuing a SIO 
to print that character. 
Whenever CINT posts the console processor, it also turns on the 


action-required flag, CFACT. This flag is tested and reset by 
the console processor. 
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5471 Console Processor 


The 5471 console processor, $CON, non-process exits until posted; 
then it checks to find what caused it to be posted. 


If input is complete, $CON replaces in the MULTI-LEAVING buffer 
pool the buffer it stole when it acknowledged the request key. 
Then it sends the operator command to HASP by calling subroutine 
SCMPR, unless the input length is zero. In any case, it continues 
by checking for request-pending. 


If a keyboard request is pending, SCON first steals a buffer from 
the MULTI-LEAVING buffer pool, to avoid a potential buffer lock-out 
problem. If no buffers are available, it leaves the request pending 
and checks for queued buffers containing messages to print on the 
5471 printer. But if the MULTI-LEAVING buffer steal was successful 
SCON resets the 5471 buffer pointer, resets the action-required and 
request-pending flags, sets the input-in-process flag, and issues 

a SIO which turns on the proceed light and enables all keyboard 
interrupts. Then it non-process exits until posted. 


If SCON was not posted for the above reasons, it investigates out- 
put possibilities. If either input or output is in process, it 
cannot start output; it again non-process exits until posted. But 
if neither input nor output is in process, and if there is no end- 
' of-forms indication from the 5471, $CON checks for output. First 
it checks the error message table, a circular table, to see if any 
error messages are outstanding. If so, it expands a four-byte coded 
error message to the equivalent eight-character hexadecimal repre- 
sentation in the 5471 buffer, sets the output-in-process flag, and 
issues a SIO to start printing the first character; then it non- 
process exits until posted, while CINT prints the remaining char- 
acters. 


If no error messages are outstanding, SCON checks for messages from 
HASP. If there are some, SCON calls subroutine $DCOM to decompress 
a message. In order not to be forced into a wait condition on sub- 
sequent calls to $DCOM, SCON then checks whether the MULTI-LEAVING 
buffer from which the message was decompressed contains more 
messages; if not, SCON frees it by calling subroutine SFREEBUF. 
Then $SCON initiates printing of the message by setting the output- 
in-process flag and issuing a SIO to print the message's first 
character. Then $CON non-process exits until posted. 
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9475 Console Interrupt Routine 


Upon an interrupt from the 5475 Data Entry Keyboard, the 5475 
Console Interrupt Routine (CINT) checks the cause of the inter- 
rupt. An interrupt may be caused by a data key, the field-erase 
function key, the release function key, the error-reset function 
key, any other function key or switch, or the multipunch key. A 
multipunch key interrupt is treated as an error and requires the 
operator to depress the error-reset key; all function keys and 
switches other than those mentioned are treated as no~-operation 
keys. 


A data key interrupt causes CINT to place the keyed character in 
the 5475 buffer. CINT then increments the buffer pointer by 

one; if the buffer pointer now points outside the buffer, CINT 
performs the release key function. Otherwise CINT adds one to the 
column indicated and exits. The exit process consists of issuing 
a LIO for the column indicators and a SIO for the keyboard. 








An interrupt from the field-erase key causes CINT to reset the 
buffer pointer, set the column indicators to display "01", and 
exit. 


An interrupt from the release key causes CINT to post the 5475 
console processor for work, set the SIO in CINT to disable the 
keyboard, and exit. 


Any of several error situations causes CINT to turn on the error 
light. It does this by setting its SIO to X'23', which also 

locks all data keys. When an interrupt other than from the error- 
reset key occurs and the error light is on, CINT exits without 
further processing. But if the interrupt was from the error-reset 
key, CINT resets the SIO to its normal value of X'4F' and exits. | 
Conditions which cause the error light to come on are a multipunch 
interrupt indication, no interrupt indication, or two or more of 
the interrupt conditions data key, function key, and multipunch 
key. | , 
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5475 Input Console Processor 


When posted for WORK by CINT, the 
(SCON) sends the operator command 
SCMPR, unless the input length is 
the column indicator save area to 


pointer, and sets to X'4F' the SIO in CINT. 


5475 Input Console Processor 
to HASP by calling subroutine 
zero. In any case, it resets 
"01", resets the 5475 buffer 
Then SCON turns 


off the column indicator display (to avoid burning out the lights), 
issues a SIO to unlock the keyboard and enable interrupts, and 


again waits for WORK. 
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SCONP = 5203 Output Console Processor 


When posted for WORK, SCONP checks the printer-availability flag. 
This flag is on if $PRINTER is currently printing a job. If the 
flag is on and RMTGEN specified &PRTCONS=2, SCONP frees all 
MULTI-LEAVING buffers currently queued on its Function Block 
(using subroutine SFREEBUF) and again waits for WORK. But if 
RMTGEN specified &PRTCONS=1, S$CONP checks to see if it should 
force messages to be printed on the 5203. It does this by com- 
paring the number of MULTI-LEAVING buffers currently queued on its 
Function Block with a maximum number. If the comparison is low, 
it non-process exits until either the comparison is not low or 
the printer-availability flag is off; if the comparison is not 
low, it performs a page eject before starting to print messages. 


To print messages, SCONP first prevents the logical printer routine 
SPRINTER from using the 5203 simultaneously; to prevent this, it 
sets the UNIT wait bit in S$PRINTER's Function Block. Then SCONP 
attempts to find an outstanding four-byte coded error message; if 
it finds one, it expands the message to eight bytes and causes it 
to be printed. 


If no error messages are outstanding, SCONP checks for messages 
from HASP. If there are some, it calls $DCOM to decompress a 
message. In order not to be forced into a wait condition on sub- 
sequent calls to S$DCOM, SCONP then checks whether the MULTI-LEAVING 
buffer from which the message was decompressed contains more mes~ 
sages; if not, it calls $FRE 





SEBUF to free the buffer. Then SCONP 
causes the message to be printed, by marking the print buffer busy 
and non-process exiting until it again becomes free. All messages 
printed by SCONP are single~spaced. 


Finally, if no messages remain to be printed, SCONP examines the 
printer-available bit to determine if it interrupted a job to print 
messages. If so, $CONP does a page eject. In any case, SCONP 
resets the UNIT wait bit to unlock SPRINTER and waits for work 
again. 
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BSCINT - BSCA Interrupt Routine 


The BSCA Interrupt Routine, BSCINT, processes all interrupts and 
performs all error recovery for the Binary Synchronous Communications 
Adapter. Processing is always initiated by one of three types of 
op-end interrupts - end-of-transmit, end-of-receive, and 2-second- 
timeout. 


For an end-of-transmit interrupt, BSCINT gains control at BSXOPE. 
If no hardware errors have occurred, it starts a receive operation; 
otherwise it uses subroutine BIDISCON to recover from a possible 
disconnect and, on return, attempts to re-transmit. 


For an end-of-receive interrupt, a great deal more is done. After 
having computed the number of received bytes, BIRCV checks for 
hardware errors; if any occurred, it uses subroutine BIDISCON and 
then transmits a negative acknowledgment (NAK) to HASP. 


If no hardware error occurred, the starting sequence is checked at 
BCROK - it is valid if it is a NAK or a DLE-ACKO or if its second 
byte is STX and the last byte received is ETB. If none of these 
is the case, BCROK sets up an error message of 03SSSS00 (where 
SSSS is the starting sequence) and then transmits a NAK to HASP. 


The section of code responsible for transmitting a NAK first checks 
whether the wait-a-bit (WAB) sequence had been transmitted most 


‘recently; if so, it transmits the WAB sequence again rather than a 


NAK. If not, it determines if more than five bytes had been 
received. Since the buffer used for a receive is the same as that 
used for a transmit, the receive operation may have overlaid some 
or all of the transmitted data; since the starting or ending se- 
quence was incorrect or a hardware error occurred, BSCINT has not 
yet received a positive acknowledgment for the transmitted data. 
To alleviate this problem, the first five bytes of the transmit 
data were saved before the buffer was transmitted. If the receive 
Operation overlaid more than these bytes, the buffer cannot again 
be transmitted; the first two saved bytes are replaced with a 
DLE-ACKO and the transmit ending address is set to the starting 
address plus two. Then the routine transmits a NAK to HASP. 


If the received starting sequence was a NAK, the interrupt routine 
sets up an error message of 02000000 (NAK received), refreshes the 
first five bytes of the buffer and the transmit ending address, and 
re-transmits the buffer to HASP. 


If the received sequence was DLE-ACKO, BSCINT sets flags to show 
SBSCA that a transmit-receive operation has completed; then it 

exits by starting a two-second timeout. If the two-second timeout 
completes before SBSCA has cancelled it, BSCINT sets the two-second- 
timeout-complete flag and exits by disabling BSCA interrupts. 
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If the second byte of the received starting sequence was STX and 
the ending byte was ETB, BSCINT validates the Block Control Byte 
. (a HASP control byte which contains a modulo-16 received-block 
count) and saves the two-byte HASP Function Control Sequence. If 
‘the BCB is as expected, interrupt processing concludes as for 
DLE~ACKO. Otherwise the STX is changed to X'FF' as a signal to 
SBSCA to throw the buffer away and the difference between the 
received BCB and the expected BCB is examined. If the modulo-16 
difference is -2 or -1, BSCINT tolerates the error; otherwise it 
sets up an error message of 02rree00 to display the received and 
expected BCB's, and it builds and transmits to HASP a BCB-error 
control sequence. 


System/3 Remote Tern 





ilnal Processor - Page 4.23.24 


228 


HAS P 
SBSCA - Communications Adapter Processor 


SBSCA non-process exits until BSCINT posts it with an indication 
that either an error message awaits synchronous processing, a re- 
ceive operation has completed without error, or a two-second 
timeout has occurred. | 


If an error message was produced by BSCINT, it must be placed in 
the circular error message trace table by a synchronous processor 
rather than an interrupt routine, since the $MSG subroutine is not 
re-entrant. S$BSCA calls the SMSG subroutine to add the error mes- 
Sage to the trace table. 


If a receive operation has ended without error, $BSCA processes the 
received buffer, which is always the first buffer on $SBSCA's buffer 
chain. If the buffer does not contain text, SBSCA frees it imme- 
diately. Otherwise SBSCA inspects the buffer's first RCB (or first 
SRCB if the RCB indicates a MULTI-LEAVING control record). If the 
RCB is zero (typical when HASP sends wait-a-bit) SBSCA frees the 
buffer. Otherwise $BSCA compares the RCB (or SRCB) with the field 
FBRCB in all FB's eligible to receive buffers; if there is no 
match, it frees the buffer. But if a match is found, $BSCA again 
determines if the first record in the buffer i: a control record. 
If so, it posts the subject FB for PERM and resets its POST bit to 
indicate a possible early post (the POST bit is turned on by sub- 
routine SPERM); then it frees the buffer. But if the buffer con- 
tains data records, $BSCA dequeues the buffer from its own FB and 
queues it onto the subject FB, in the process reducing its own 
buffer count by one, increasing that of the subject FB by one, and, 
if the subject FB's buffer count (FBBCT) becomes equal to or greater 
than the subject FB's maximum buffer count (FBBMX), resetting the 
appropriate bit in the master Function Control Sequence S$FCS by 
using FBFCS. 


Having processed the received buffer or if a two-second timeout 
occurred, S$BSCA determines what and when it is to transmit. S$BSCA 
inspects the most-recently-received FCS for the wait-a-bit; if it 
is on, $BSCA transmits immediately a DLE-ACKO (or a wait-a-bit 
sequence if there are no free MULTI-LEAVING buffers). 


But if the received wait-a-bit is off, $BSCA inspects its buffer 
chain. If the chain is non-empty, SBSCA prepares to transmit the 
first-chained buffer to HASP. Each buffer on the chain has the 
following format, as set by subroutine SCKLEN: 
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[Per | to next puffer | 
| peo” to 3a- Eooiaae byte (ETB- 2)| | $BSCA overlays these 
|| STX, BCB, FCS1, FCS2. 


First RCB | 


||First SRCB | 


&MLBFSTZ 


i EOB (X‘'00') | ETB (X'26') | ETB is not necessarily 





If there is no text buffer to send, SBSCA checks for a free MULTI- 
LEAVING buffer. If there is no free MULTI-LEAVING buffer, SBSCA 
sends a wait-a-bit sequence if a two-second timeout has occurred; 
otherwise it non-process exits awaiting either a two-second timeout 
or the setting of its BFPOST flag by subroutine SCKLEN. 


If a free MULTI-LEAVING buffer is available, SBSCA will use it only 
if the last-received buffer was a text buffer (that is, its second — 
byte was STX) or if the master Function Control Sequence, SFCS, had 
changed from that last transmitted to HASP. If the latter is the 
case, SBSCA will transmit immediately a logical acknowledgment (DLE 
or SOH, STX, BCB, FCS1, FCS2, EOB, ETB) to inform HASP of the 
change; if the former is the case, SBSCA will transmit a physical 
acknowledgment (DLE, ACKO). If neither is the case, $BSCA will 
non-process exit until either a two-second timeout occurs (where- 
upon it will send DLE-ACKO or the wait-a-bit sequence) or $SCKLEN 
sets BFPOST (whereupon $BSCA will again check for a received 
Walt-a-bit). 


To get a free buffer S$BSCA uses subroutine BSGBUF, which queues the 
buffer on SBSCA's buffer chain (FBBUF) in last-in, first-out fashion 
and increments its buffer count (FBBCT) by one. Additionally, a 
part of BSGBUF sets up the transmit starting address, receive 
Starting address, and receive ending address, and may be called 
separately from BSGBUF . 
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SLEOF, $PERM, S$REQ - Control Sequence Subroutines 


These subroutines transmit to HASP certain control sequences 
required for proper operation of HASP MULTI-LEAVING Remote Job 
Entry: logical end-of-file, permission-granted, and request-— 
permission. 


SLEOF sends the sequence RCB, SRCB, SCB where RCB is taken from 
the FB pointed to by register 2 (FBRCB), SRCB is X'80', and SCB 
is X'00' (a string control byte of X'00' is an end-of-logical- 
record SCB; occurring immediately after an SRCB, such an SCB 
indicates a zero-length record). 


SPERM sends the sequence RCB, SRCB, EOB where RCB is X'AO' (per- 
mission-granted for function described in SRCB), SRCB is taken 
from FBRCB of the FB pointed to by register 2, and EOB is X'00' 
(a zero RCB indicating logical-end-of-transmission-block) . 

SPERM also sets the bit EWFPOST in the field FBEWF; this "early- 
post" bit is reset by SBSCA when it finds any permission- type 
control record whose SRCB matches FBRCB. 


SREQ sends the sequence RCB, SRCB, EOB where RCB is X'90' (request- 
permission for function described in SRCB) and SRCB and EOB are as 
described for SPERM. 


Code common to all three routines requests from $CKLEN three bytes 
Of space in a MULTI-LEAVING buffer, moves the three-byte sequence, 


and calls SBFLUSH to truncate the buffer and queue it on SBSCA's 
buffer chain. 
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SDCOM - Decompression Subroutine 


SDCOM is called by one of the output processors (such as SPRINTER) 
to decompress a logical record from a MULTI-LEAVING buffer into 
an area whose starting address is supplied by the caller. (HASP 
transmits all data records to MULTI-LEAVING terminals in a com- 
pressed and truncated format). If decompression is successful, 
$DCOM returns to the caller at an offset of three bytes; if $DCOM 
recognized a logical-end-of-file, it returns at an offset of zero. 


To decompress a logical record, $DCOM first examines the address 
in FBCURL, a two-byte field in the caller's FB reserved for the 

use of $DCOM. If that field is non-zero, it has previously been 
set by $DCOM to point to the RCB following the last-decompressed 
logical record in the current buffer. If that RCB is not X'00', 
$DCOM decompresses to the caller's area (which must be two bytes 
longer than the maximum record length) the record following the 

RCB, moves the SRCB to FBSRCB, saves the address of the next RCB 
in FBCURL, and returns to the caller as explained above. 


But if FBCURL is zero, $DCOM checks if more buffers are queued on 
the caller's FB. (If FBCURL is non-zero but the RCB to which it 
points is zero, $DCOM first frees the current buffer and then pro- 
ceeds as if FBCURL were zero.) 


If one or more buffers are queued, $DCOM selects the first buffer, 
points to its first RCB, and decompresses a logical record as 
above. But if no buffers are queued, $DCOM waits for WORK, to be 
posted by S$BSCA when the next buffer for the same output device 

1s received. 


The output buffer's address is specified by the caller in field 
FBAREA; on return, SDCOM replaces this field by the address of 
the last-plus-one output byte. 
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SCMPR - Compression Subroutine 


SCMPR compresses data from a user-specified input area to a local 
workarea and transmits it to HASP by calling subroutine $CKLEN. 


When called, SCMPR examines the status of its local workarea. If 
the workarea is busy, $CMPR has been called by some other proces- 
sor and has in turn called $CKLEN; $CKLEN is non-process exiting 
until it can find sufficient bytes in a MULTI-LEAVING buffer to 
allocate to S$CMPR. In this case, $CMPR non-process exits until 
its workarea becomes free. 


When the workarea is free, S$CMPR compresses into it the text pointed 
to by FBAREA. Compression consists of either full compression 

and truncation, only truncation, or neither compression nor trun- 
cation, as selected by the setting of the RMTGEN variable &COMP=. 
Once the record is compressed, SCMPR calculates its compressed 
length and calls $CKLEN with a request for the number of bytes it 
requires in a MULTI-LEAVING buffer. When SCKLEN returns, $CMPR 
moves the compressed record, shows its workarea free, and returns 

to the caller. 


System/3 Remote Terminal Processor - Page 4.23.29 


233 


HAS P 
SCKLEN - MULTI-LEAVING Buffer Allocation Subroutine 


SCKLEN returns to its caller the address ina MULTI-LEAVING buffer 
of the rightmost byte of an area whose length is specified by the 
caller. | 


The caller specifies a length in register one. If $CKLEN has a 
current buffer, its current buffer pointer points to the last- 
allocated byte. It adds to this the caller's specified length. 

If the resultant address is lower than two bytes before the end of 
the buffer, SCKLEN saves this address as its current buffer pointer 
and returns this address to the caller in register one. But if the 
resultant buffer address is not lower than two bytes before the end 
of the current buffer, $CKLEN truncates the buffer, queues it on 
SBSCA's buffer chain, and posts SBSCA by turning on flag BFPOST 

in byte BCF1. To truncate a buffer, S$CKLEN moves the current buf- 
fer pointer to its first two bytes and the sequence EOB, ETB 
(X'0026') to the two bytes after the byte pointed to cay the current 
buffer pointer. 


After having truncated and queued the current buffer or if on entry 
there was no current buffer, but not if entered via entry point 
SBFLUSH (in which case SCKLEN returns immediately after truncation 
and queuing), SCKLEN attempts to get another buffer to satisfy the 
caller's request; if no buffer is free, it non-process exits until 
one comes free. It initializes the current buffer pointer to point 
to what will eventually be the buffer's FCS2 byte. It initializes. 
a pointer to the last byte available in the buffer, and it saves 
the address of the buffer's chain word in a third pointer. Then 

it allocates space for the caller and returns, as above. 
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SFREEBUF - MULTI-LEAVING Buffer Free Subroutine 


SFREEBUF dequeues the first buffer from the buffer chain word FBBUF 
of the FB addressed by register two upon entry; subtracts one from 
FBBCT, the count of buffers enqueued upon that FB; and compares the 
new count with FBBMX. If the compare is low, $FREEBUF OR's the two 
byte field FBFCS into the two-byte field $FCS and compares the 
resulting $FCS with BCXFCS, the FCS last transmitted to HASP. If 
SFCS is not equal to BCXFCS, $FREEBUF posts SBSCA. 


In any case, $FREEBUF queues the just-dequeued buffer on chain word 
SMLPOOL in last-in, first-out sequence. If the system was generated 


for a 5471 console, $FREEBUF posts SCON, the console processor. 
Then SFREEBUF returns to its caller. 
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ABEND - Core Dump Subroutine 


ABEND produces a core dump on the 5203 printer. The code for 
ABEND is assembled only if the RMTGEN specification &DEBUG=l 
has been used. &DEBUG=1 also causes the generation of extra 
debugging code throughout the terminal program; some of the 
extra sequences of code generated contain conditional branches 
to ABEND. ABEND may also be called from the CE panel of the 
System/3 by setting the IAR to its address. 


Each line produced by ABEND consists of a four-character address, 
64 characters representing the 32 bytes starting at that address, 
and their printable equivalent in 32 more characters, bounded at 
the left and the right by a single asterisk; or four asterisks 

in the address position followed by blanks, to indicate that all 
of core up to the next line's address or the end of core would 
have printed the same as the previous line. The ABEND dump rou- 
tine requires a printer with at least 120 print positions; if a 
96-print-position printer is used, not all of the EBCDIC portion 
Of the line will be printed. 


The first six bytes of printed core contain the address recall 
register, register one, and register two as of the time ABEND 
gained control; the remainder of core is intact. 
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$LOG - HASP Error Recording Subroutine 


SLOG is a re-entrant subroutine which maintains in-core error 
recording counters. Each counter is two bytes long and has a 
maximum count of 65535. There are eight counters for each of the 
following bytes: 


1442 Status Byte 
1442 Status Byte 
BSCA Status Byte 


2 (if &$31442=1) 

1 

2 
5203 Status Byte 2 

1 

1 


(if &S31442=1) 


5203 Status Byte 
5424 Status Byte 


The counters are captioned, printed, and reset by IHEREP at 
program load time and thus form a permanent record of unit checks 


associated with the above devices. Only those counters which 
represent unusual unit checks are printed by IHEREP. 
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SMSG - Error Message Tracing Subroutine 


$MSG adds the four-byte coded entry addressed by register one to 
the circular trace table of error messages. This table is examined 
by the 5471 console processor and under certain conditions by the 
5203 output console processor; $MSG posts whichever of these pro- 
cessors has been generated. 


The various error messages supplied to this routine by its callers 
are explained in the System/3 Operator's Guide. 
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SINIT - Initialization Routine 


SINIT gains control when program loading is complete. It sets 
the print chain image, reads and processes REP cards, sets the 
5203 forms length register, sets the 5424 print buffer register, 
establishes communication, sets up buffers, and exits to the 
commutator. 


To set up the print chain image, SINIT reads the printer status 
bytes. If the 48-character-set bit is on, it moves the. LC 
image to the image area; otherwise it moves the PN image. Then 
SINIT starts procesSing reps. 


The format of a REP card is 


column 2 9 17 
REP addr rep-data 


where "addr" must be a valid hexadecimal core address of exactly 
four characters (or four blanks) and "rep-data" is a sequence of 
one or more replacement groups with the last group terminated by 

a blank and all others terminated by commas. A replacement group 
is a string of 2n (n any integer) hexadecimal characters. The 
blank after the last replacement group may be followed by comments. 


Starting at the address specified by "addr", the REP routine will 
store bytes one at a time corresponding to byte pairs of the "rep- 
data" taken from left to right. If the "addr" specification is 
blank, bytes will be stored starting at the first byte after the 
byte last used by the preceding REP card (or at zero if there was 
no preceding REP card). A REP card whose "rep-data" field con- 
tains no data is valid; its "addr" field (if any) specifies the 
address of the first byte to be repped if the next REP card's 
"addr" field is blank. 


To process reps, SINIT reads a card from the primary hopper of the 
MFCU; a read error will give an F3 halt. If the card image con- 
tains "REP" in columns 2-4, it is processed according to the above 
Specifications, with absolutely no validity-checking, and SINIT 
reads another card, as above. 


If the card image contains "&MLBFSIZ=" starting in column 1, SINIT 
converts to binary the specified decimal buffer size (which must 
immediately follow the equal sign and be terminated by a blank) 

and substitutes the result for the default buffer size. Then SINIT 
reads the next card, as above. 


If the card image contains "/*SIGNON" starting in column 1, SINIT 
overlays the default sign-on card with it and continues as if the 
card were an EOR card. 
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If the card image contains "EOR" (end-of-reps) in columns 2-4, | 
SINIT terminates rep processing, loads the 5203 print forms lengtl | 
register and the 5424 print buffer address Begeeren and establishes ~ 
- communications. 


To establish communications, SINIT first disables and then enables 
the BSCA. Next, it examines the sign-on card to see if dialing 
information was specified. If so, it determines the starting and 
ending addresses for the telephone number (which is not checked 

for validity) and loads these values into the current and stop 
address registers after first ensuring that the data line is unoc- 
cupied. (If the data line is occupied, SINIT assumes the operator 
dialed and waits for the data set to become ready.) After starting 
an auto-call operation and looping until an op-end interrupt occurs, 
SINIT checks for timeout status; if so, the auto-call unit returned 
an abandon-call-and-retry signal and a CA halt (call-aborted) occurs. 
When the operator resets the halt, the entire logic starting with 
disable-BSCA will be re-executed. But if the timeout bit is off, 
SINIT assumes the call was successful and loops until a dataset- 
ready indication occurs, as above. : 


When the data set becomes ready, SINIT transmits the two-byte 
sequence SOH-ENQ, a sequence recognized by HASP as a request from 
a MULTI-LEAVING terminal. If the receive part of this transmit/ 
receive command ends with timeout, the operation is repeated; if 
it ends with any other abnormal status, one of two things occurs. 
_If the system was generated with &DEBUG=1l and the address knobs 
on the System/3 console are set to any odd address, the System/3 
halts; the halt indicators display a hexadecimal image of the 
BSCA error status byte. Otherwise, and when the operator resets 
the halt, the entire logic. starting with disable-BSCA will be 
re-executed. 


If the receive operation ended normally, the two received bytes 
should be DLE-ACKO. If they are not, the transmit/receive opera- 
tion is performed. | 7 


If DLE-ACKO was received correctly, the message "COMMUNICATION 
ESTABLISHED" is printed on the 5203. If a 5471 was specified when 
the system was generated, its interrupts are enabled and the same 
message is printed on it. If a 5475 was specified, its interrupts 
are enabled. SINIT now performs buffer initialization. 


Buffer initialization consists of three steps and overlays the 
initialization code with MULTI-LEAVING buffers. As the first 

step, the value of MULTI-LEAVING buffer size is set in the various 
locations throughout the program that requires it; it may have 

been changed by the &MLBFSIZ control card. Step two moves the 
actual buffer initialization code to low core, where it is executed 
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as step three. Execution consists of chaining together all 
buffers but the first buffer (which contains the sign-on record 
and is afterward queued to the $BSCA processor) with the chain 
Origin at SMLPOOL. | 


When buffer chaining is complete, the sign-on buffer is queued 

as mentioned and control passes to the commutator. $COM gives 

control in its turn to the $BSCA processor, which as a special, 
first-time function transmits to HASP the buffer containing the 
Sign-on card image. 
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52/0 : HASP CONTROL SERVICE PROGRAMS 


This section contains detailed internal information about each of 
the HASP Control Service Programs and is intended primarily for 
use by systems programmers. 
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oe HASP DISPATCHER 
oe ee | HASP Dispatcher - General Information | 


The HASP Dispatcher is responsible for the allocation of the CPU 
time used by the HASP Task to each of the HASP Processors. 


ee ay, HASP Dispatcher - Program Logic 


The HASP Dispatcher receives control each time the HASP task is 
dispatched by the Operating System and utilizes an ordered queue 
of Processor Control Elements (PCE's) to distribute the CPU time 
among the HASP Processors. The Event Wait Field (EWF) in each 

PCE (see Figure 8.2.1) is a two byte field which is used to control 
the dispatchability of the Processors. Any Processor or Control | 
Service Routine may issue a $WAIT macro-instruction at any time 
which turns on a particular bit in the EWF corresponding to the 
event SWAITed on and returns control to the HASP Dispatcher to 
allow other processors to be dispatched. The Processor (or | 
Service Routine) will not be given control again until some other 
system function issues a $POST to its EWF for the event SWAITed on. 


The events reflected by the EWF fall into two categories: the 
‘first of which is the synchronization of the use of common system 
resources such as buffers, direct-access space, etc. With the 
exception of the general $POST bit SEWFPOST, the bits in the first 
byte of the EWF field are used to indicate the particular resource 
being SWAITed on and corresponds exactly to the Event Completion 
Field (ECF) in the Dispatcher. The ECF is $POSTed whenever a 
resource becomes available and is propagated through all processor 
EWF's by the Dispatcher. Thus, if a track becomes available on a 
direct-access device, every processor (PCE) which has issued a 
SWAIT for a track will be put in contention for CPU time to try 

to obtain the track or tracks that have been released. 


The second byte of the EWF is used to synchronize a processor with 
respect to a specific event, applicable only to that processor, 
such as a particular I/O completion. This section of the EWF must 
be $POSTed directly by the system routine performing the required 
function (additional details regarding $WAIT/SPOST events may be 
found in Section 9.8). 


When scanning the PCE chain, the HASP Dispatcher, upon discovering 
a zero EWF (no events being SWAITed on), will enter the code 
controlled by the PCE immediately below the prior $WAIT which had 
returned control to the Dispatcher. All registers of a processor 
which issues a $WAIT are preserved in the PCE and are reloaded 
prior to entering the processor (register "R15" is destroyed by 
the SWAIT macro to provide the address of the $WAIT, i.e., the 
resume point). A processor may return control to the Dispatcher 
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only by means of the S$WAIT macro. In the event any $POST macro 
was executed by the processor dispatched or by any of the HASP 
asynchronous service routines the Dispatcher's ECF field will be 
altered to reflect the $POST. The general $POST bit represents 

a SPOST of a specific processor (second byte of the EWF). If the 
ECF field indicates no $POST has occurred, the HASP Dispatcher 
continues to scan down the PCE chain starting with the next PCE. 
However, if the ECF field indicates S$POSTs have occurred, the 
SPOST for the general $POST is removed and scanning is resumed 

at the beginning of the PCE chain, after promulgating any remaining 
ECF $SPOST indicators. 

Upon reaching the end of the PCE chain, the Dis- 
patcher examines the processor active count to determine if any 
jobs are being processed. If an active job is in the system 
(active count # 0) an OS WAIT state is entered to wait for some 
external event (I/O interrupt, etc.) to activate HASP again. This 
WAIT allows use of the CPU by other tasks in the system. If no 
jobs are active, the message 


"ALL AVAILABLE FUNCTIONS COMPLETE" 


is sent to all operator consoles and HASP is placed into the WAIT 
State. 


When scanning the PCE chain, the Dispatcher detects the special 
case Of a PCE which is not dispatchable (PCEEWF is not zero) but 
is $WAITing only on the OROL bit. This situation is created when, 
while the PCE was S$WAITing on other event(s), the Overlay Area 
being used by the PCE is preempted by the Overlay Roll Processor 
for other use (see Section 4.20). Subsequently, the other event(s) 
being SWAITed on are SPOSTed allowing the Dispatcher to detect the 
"OROL only". The Processor in such a condition is not entered but 
is made to call Overlay Service. The actions performed are iden- 
tical to those described for SLINK Service in Section 5.16.2, 
beginning with the fourth paragraph describing search of Overlay 
Areas. The Processor will be entered by Overlay Service if the 
requested routine is in memory, or will be SWAITed on OLAY 
allowing the Dispatcher to continue its PCE scan. 
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Dee INPUT/OUTPUT SUPERVISOR 


ser ae Input/Output Supervisor - General Description 


The HASP Input/Output Supervisor ($EXCP) is used to interface all 
HASP Input/Output requests with the Operating System Input/Output 
Supervisor. Through the use of SEXCP the HASP processors can 
remain "device independent" through the wide range and number of 
HASP direct-access devices. In addition, SEXCP also provides all 
required I/O appendages for OS IOS and for the $POSTing of I/O 
completions to each processor. | 


Dw 2i2 Input/Output Supervisor - Program Logic 


The only interface between the HASP Input/Output Supervisor and 
the using processors is the Device Control Table element (DCT), 
which is passed via the $EXCP macro-instruction when I/O is 
requested. (Additional information concerning the DCT and the 
SEXCP macro may be found in Sections 8.5 and 9.5 respectively.) 
Upon entry to SEXCP the address of the buffer to be used is 
obtained from the DCT and the IOB (appended to every buffer) is 
initialized. The user's Event Wait Field (EWF) address is moved 
from the DCT to the buffer and a pointer to the DCT is placed in 
the buffer. If the DCT is a direct-access type, the coded track 
address from the DCT is used to compute MBBCCHHR. 


The IOB is now scheduled for I/O through the use of the standard 
OS Execute Channel Program macro-instruction (EXCP) and immediate 
return is made to the caller. Each I/O request issued by HASP 
has an I/O appendage list specified which causes the appropriate 
channel end appendage in SEXCP to be entered upon termination of 
the I/O. Since these appendages are entered asynchronously with 
HASP operation, the buffer associated with the completed I/O is 
scheduled for synchronous HASP processing by the Asynchronous 
Input/Output Processor. The HASP task is POSTed, and immediate © 
return is made to IOS. (The action taken by the Asynchronous 
Input/Output Processor is explained in Section 4.8.) 


A separate channel end appendage is provided for remote terminal 
operations. This appendage correlates the channel end conditions 


with the commands executed and provides special processing of con- 
ditions unique to the teleprocessing. 
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Dad JOB QUEUE MANAGER 


Dida! Job Queue Manager - General Information 


Jobs being processed or awaiting processing by a HASP phase are 
represented in an ordered queue by a Job Queue Element (see 
Figure 8.6.1). 


The Job Queue Management routines are used by the HASP Processors 
to insert, alter, locate, and remove Job Queue Elements. The 
Queue Elements are maintained in priority at all times with the 
highest priority element at the top of the active chain. There 
are six Job Queue Element routines which are called by issuing 
the following macros: SQADD, SQREM, SQGET, SQPUT, S$QLOC, and 
SQSIZ (see Section 9.3). The Job Queue Elements are arranged 

in two chains. The active chain contains the Job Queue Elements 
for all the jobs in the system at a given time. The free chain 
contains all the Queue Elements which are not in use. 


5.3.2 SQADD Routine - Program Logic 


The SQADD routine is called whenever a Queue Element is to be added 
to the active queue. If the Checkpoint Processor is waiting for 
the checkpointed information to be written onto the SPOOL] disk, 
this routine enters a HASP SWAIT state. Whenever the Checkpoint 
Processor's I/O is complete, the free queue chain is tested to see 
if any free Queue Elements are available. If none are available, 
control is returned to the caller with a condition code of zero. 

If a Queue Element is available, the correct slot within the active 
queue chain is located by comparing the priority of the element to 
be added with the priorities of the elements in the active chain. 
When the priority of the new element is higher than the priority 

of the element in the active chain, the free Job Queue Element is 
extracted from the free queue chain and inserted into the active 
Chain. All the information for the new Job Queue Element is moved 
from the location pointed to by register "R1" into the new Job 
Queue Element. Then the HASP Dispatcher's Event Control Field is 
SPOSTed to indicate that a Job Queve Element is available. The 
Checkpoint Processor's PCE is also $POSTed so that it will be given 
control to write the updated Job Queue onto the SPOOLI] disk. The 
condition code is set non-zero and control is returned to the 
caller. Upon return, register "RO" contains the address of the 
associated Job Information Table Entry. 
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5.3.3 SQREM Routine - Program Logic 





The SQREM routine is entered to remove a Job Queue Element from 
the active chain. It will enter the calling Processor into a 
HASP SWAIT state if the Checkpoint Processor's I/O is not complete. 
When the Checkpoint Processor's I/O is complete, the Job Queue 
Element that is to be removed is located by comparing its job 
number with the job numbers of the queue elements in the active 
chain. If an equal comparison is not found, control is returned 
to the caller with the condition code set to zero. If a match 

is found, the Job Queve Element is removed from the active chain 
and added to the top of the free chain by updating all the chain 
pointers. The Checkpoint Processor's PCE is $POSTed so that it 
will be given control to checkpoint the Job Queue. Then control 
is returned to the caller with the condition code set non-zero to 
indicate that the Queue Element was successfully removed. 


a ee ee SQGET Routine - Program Logic 


The SQGET routine is entered to acquire a Job Queue Element in a 
specified queue so that the job may be processed. The active queue 
chain is searched for a Job Queve Entry of the specified type (e.g., 
execution, print, punch, or purge) which is not in hold status and 
not presently acquired. If such a job is not present, control is 
returned to the caller with the condition code set to zero. If 

an acceptable queue element is found, the QENTBY bit is turned on 
in the queue element to show that the element has been acquired, 
and control is returned to the caller with the condition code set 
non-zero, register "R1" pointing to the job queue element that was 
acquired, and register "RO" pointing to the associated Job Infor- 
mation Table Entry. Whenever the system is in a drained status, 
this routine will be crippled such that control will always be 
returned to the caller with the condition code set to zero to 
indicate that no available Job Queue Elements are present. 


523.5 SQPUT Routine - Program Logic 





The $QPUT routine is entered to return a previously acquired Job 
Queue Element to the active chain, but with a new queue type. It 
will enter the calling Processor into a HASP SWAIT state if the 
Checkpoint Processor's I/O is not complete. When the Checkpoint 
Processor's I/O is complete, the job number of the queue element 

to be returned is compared with the job numbers of the queue ele- 
ments in the active queue. If the job number is not found, control 
is returned to the caller with the condition code set to zero. If 
a match is found, the new queve type is set, the HASP Dispatcher's 
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Event Control Field is posted to indicate that a Job Queue 
Element is available to be acquired, and the Checkpoint Proces- 
sor's PCE is $POSTed so that it will be given control to write 

the updated Job Queue onto the SPOOL] disk. If the QUEPURGE bit 
is on in the queue element (indicating that the job has been 
deleted), the job queue element is placed in the punch queue by 
moving the punch queue type into the queue element's QUETYPE 
field. If the QUEPURGE bit is not on, the job queue element is 
placed in the queve indicated by register "RO" upon entry to 

this routine. The QENTBY bit is turned off to indicate that this 
queue entry has been returned, the condition code is set non-Zero, 
and control is returned to the caller. Upon return, register "Rl" 
contains the address of the Job Queue Entry just returned and 
register "RO" contains the address of the associated Job Infor- 
mation Table Entry. 


523.6 SQLOC Routine - Program Logic 


The SQLOC routine is entered to obtain the Job Queue Element address 
when the job number is known. The job number is compared with the 
job numbers in the active chain. If a match is not found, control 
is returned to the caller with the condition code set to zero. If 

a match is found, the condition code is set non-zero, and control 

is returned to the caller with register "Rl" containing the lo- 
cated Job Queue Element's address and register "RO" containing the 


‘associated Job Information Table Entry address. 


5.3.7 $QSIZ Routine - Program Logic 


The SQSIZ routine is entered to obtain the number of Job Queue 
Elements in a given queue type, route, class, and forms. The num- 
ber of jobs of the specified type (excluding jobs in hold status) 
are counted, and control is returned to the caller with register 
"Rl" containing this count. If register "Rl" is non-zero, the con- 
dition code is set non-zero, and if it is zero, the condition code 
is set to zero. Whenever the system is in a drained status, this 
routine is crippled so that control is always returned to the 
caller with register "Rl" zeroed, and the condition code set to 
zero to indicate that no jobs are available in the specified job 
queue. 


Job Queue Manager - Page 5.3-3 


249 





HAS P 


234 tac Et eied 
5.4.1 





Buffer Manager - General Description 


The Buffer Management routines are responsible for the allocation 
of the dynamic memory area (Buffer Pool) of HASP. Fixed-size buf- 
fers in this area are allocated and de-allocated to HASP Processors 
and Routines via the S$GETBUF and SFREEBUF macro-instructions (see 
Section 9.1). | 


524a2 





Buffer Manager ~ Program Logic 


The S$GETBUF routine consists of two programs which allocate HASP 
Buffers or RJE Buffers respectively. Both programs function iden- 
tically as follows: The appropriate free buffer pointer is tested, 
and if no buffers are available, control is returned to the caller 
with the condition code set to zero. If a free buffer is present, 
the free buffer pointer is updated to point to the next free buffer; 
or, if this is the last available buffer, the pointer is zeroed. 
Then, if the debug indicator is on, a buffer .alidity checking rou- 
tine is entered to assure that the buffer is within the buffer chain. 
If it is not in the chain, the catastrophic error routine is entered; 
otherwise, control is returned to the SGETBUF routine. The condition 
code is set non-zero and control is returned to the caller with the 
buffer address in register "R1". 


The SFREEBUF routine enters the buffer validity checking routine if 
the debug indicator is on, the buffer to be freed is inserted back 
into the appropriate free buffer chain (depending upon whether the 
buffer is a HASP Buffer or anRJE buffer), and the IOBSTART field is 
updated with the address of the buffer's channel program: IOBCCW1 
(see Figure 8.3). The HASP Dispatcher's Event Control Field is 
SPOSTed to show that a buffer is available and control is returned 
to the caller. 
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5.5 UNIT ALLOCATOR 


54-541 Unit Allocator - General Description 


The Unit Allocation routines are responsible for the allocation 
and de-allocation of the Input/Output units which have been 
assigned to HASP. Device Control Tables (DCTs) are allocated and 
de-allocated to HASP Processors and Routines via the $GETUNIT and 
SFREUNIT macro-instructions (see Section 9.2). 


54.542 Unit Allocator - Program Logic 


The SGETUNIT routine scans the Device Control Table (DCT) chain 

in an attempt to find an available DCT of the requested type. If 
none are found, control is returned to the caller with the condition 
code set to zero. If an available DCT of the requested type is 
found, it is set "not available" and control is returned to the 
caller with the condition code set non-zero. The address of the 

DCT is returned in register "Rl". 


The SFREUNIT routine first examines the "Active Buffer Count" field 
of the DCT (see Figure 8.5) to see if there are any buffers involved 
in active I/O with the associated unit. If the "Active Buffer 

Count" is non-zero, the Processor is placed in a HASP SWAIT state 
until this count is reduced to zero. When the count is zero, the 
DCT is made available and control is returned to the caller. 
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“290 INTERVAL TIMER SUPERVISOR 
5.6.1 Interval Timer Supervisor - General Description 





The Interval Timer Supervisor is used by the various HASP Proces- 
sors to record the passage of a specified period of time and to 
notify the requesting Processor upon expiration of the interval. 
This routine uses the standard OS/360 timer features (STIMER & 
TTIMER) but has the additional capability to simultaneously monitor 
an unlimited number of intervals. 


9.6.2 interval Timer Supervisor ~-Program Logic 





All uses of the Interval Timer Supervisor are through the HASP 
macro~instructions SSTIMER and STTIMER which are described in Sec- 
tion 9.6. Each user of SSTIMER is required to provide a 12-byte 
(three-word) HASP Timer Queue Element (TQE), passed via parameter 
register "R1" (see Section 8.10). SSTIMER maintains a chain of all 
active TQEs in ascending order of interval magnitudes, with the 
shortest requested interval (first TQE) set on che OS STIMER queue 
(via a normal STIMER macro). Upon being entered with a new interval 
request, SSTIMER first cancels the active OS timer element with a 
TTIMER CANCEL, and reduces the interval specified in all chained 
TQEs by the elapsed portion of this interval. The requestor's TQE 
is then, after converting the requested interval to OS timer units 
(26 usec units), inserted into the appropriate place on the TQE 
chain using the first word of the TQE as a chain field. The OS 
timer is now re-activated with the interval in the first TQE in the 
chain and return is made to the caller. 


When the current OS interval elapses, the asynchronous exit routine 
in SSTIMER is entered to record the expiration. The asynchronous 
routine first reduces the intervals of all queued TQEs by the size 
of the just-elapsed interval, then SPOSTs the TIMER Processor, POSTs 
the HASP task, and returns to OS. The TIMER Processor, when dis- | 
patched, will SPOST the appropriate Processors and reset the OS 
Timer to the interval specified in the first TQE in the chain by 
issuing an STIMER macro. 


HASP Processors which have previously set an interval through 
SSTIMER may obtain the time remaining in the interval and optionally 
cancel this interval through the use of the STTIMER macro. When 
entered, STTIMER cancels the active OS interval and reduces all 
queued TQE intervals by the elapsed portion of that interval. The 
requestor's TQE is then located in the queue by comparing the ad- 
dress of the TQE passed by the macro in register "R1" to each TQE 

in the chain. When the correct TQE is found, the remaining time 
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in the interval is loaded in register "RO" for return to the 
caller. The use of the CANCEL option on the $STTIMER macro, 
which is indicated by register "Rl" containing the complement of 
the TQE address rather than the true address, causes the TQE 
to be dequeued from the chain. The OS timer is re-activated 
with the interval from the first TQE on queue and return is made 
to the caller. NOTE: A STTIMER for a TQE which is not active 
has no effect and a zero value is returned in register "RO" as 
the time remaining. 
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5.7 $WTO PROCESSING ROUTINE 


etl $WTO Processing Routine — General Description 


This routine services the $wTO macro-instruction (see Section 9. 5) 
by queuing the associated message for the Operator Console Input/Output . 


Processor. 


pWTO Processing 








This routine tests for a free message buffer. If none are available, 
it causes the requesting processor to be placed in a $WAIT condition until 
a message buffer is released. Otherwise it links to the Console Buffering 


Routine to process the message. 
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5.8 DIRECT ACCESS STORAGE ALLOCATOR 
28.4 Direct Access Storage Allocator - General Information 


This routine allocates tracks for the SPOOL volumes that were | 
on-line at IPL time. The track information is stored in the Job 
Control Table (JCT) and is also returned to the caller in register 
"Rl". The track allocation algorithm is designed to reduce seek 
time as much as possible. 


53.82 Direct Access Storage Allocator - Program Logic 


The status of each SPOOL volume is recorded and maintained in 
track group bit maps. A map is present for each module (available 
SPOOL volume). Each bit in the track group bit map represents a 
track group. If the bit is on, the track group is available to be 
allocated, and if the bit is off, the track group has already been 
allocated. Track group bit maps are also maintained in each JCT, 
but the bit definitions are opposite. Thus, if a bit is on in 

the JCT, the track group has been allocated to the JCT. 


Track groups on the SPOOL volumes are allocated whenever the JCT 
has not previously acquired any tracks or whenever all the tracks 
in the current track group which is allocated to the JCT have been 
acquired. If the JCT has already been allocated a track group, 
but all the available tracks in that track group have not been 
acquired, the next available sequential track in the track group 
is allocated to the requestor. When this happens, the track 
information in the JCT is updated and loaded into register "Rl", 
and control is returned to the caller with the condition code set 
to one. This track information is recorded in the JCT in the 
following format: MTTR, where M is the module number (one byte), 
TT 1s the track number relative to cylinder 0 track 0 (two bytes), 
and Ris the record number (one byte). The JCT track group bit 
map is also updated whenever a new track group is acquired. fThe 
update consists of ORing in the appropriate bit for the acquired 
track group in the JCT track group bit map. 


When a new track group has to be acquired, seek time is reduced 
by searching for the nearest track group + or - eight track 
groups from the last-used track group. The last-used track group 
for each track group bit map is updated each time a SEXCP is 
issued to the volume. Each track group bit map is searched for 
an available track group at the last-used track group. Then each 
track group bit map is searched for an available track group - 
one track group from the last-used track group, then + one from 
the last-used track group and this progression continues until an 
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available track group is found or the + eight track group is 
searched. If an available track group is found, the JCT track | 
information is updated and loaded into register "Rl", and control 
is returned to the caller with the condition code set to one. 

The JCT track group bit map is also updated. If a track group is 
not available within + or - eight of the last-used track group, 
another search routine is entered which inspects each byte of the 
track group maps, starting with the first byte. This search will 
continue until an available track group is found or until all of 
the active track group bit maps have been searched. If an available 
track group is found, the JCT track information is updated and 
loaded into register "Rl", and control is returned to the caller 
with the condition code set to one. The JCT track group bit map 
is also updated. If an available track group is not found, the 
operator is notified of the out-of-track condition by the fol- 
lowing message: 


SPOOL VOLUMES ARE FULL 
Then control is returned to the caller with the condition code set 


to zero and register "Rl" zeroed. 


5.8.3 Direct Access Storage Purge Routine - £ 





This routine frees all of the SPOOL volume tracks that the job has 
acquired and informs the system that these tracks are available 
to be re~acquired. 


The track group bit map in the job's Job Control Table is ORed 
into the main track group bit map to return the job's tracks back 
to the system. Then the track group bit map in the JCT is zeroed 
to indicate that this job does not have any tracks allocated to 
it. The HASP dispatcher's Event Control Field is posted to show 
that tracks are available to be acquired, and control is returned 
to the caller. | 
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Deg DISASTROUS ERROR HANDLER 


5.9.1 Disastrous Error Handler - General Description 


This routine is entered from a Processor whenever a critical SPOOL 
disk error is detected. The operator is notified of the error, and 
processing continues, although the operator should re- IPL the sys- 
tem with a cold start as soon as possible. 


5.9.2 Disastrous Error Handler - Program Logic 


When this routine is entered, a SWTO is issued to notify the operator 
of the error, and control is returned to the calling Processor. The 
message to the operator is as follows: 


DISASTROUS ERROR - COLD START SYSTEM ASAP 
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5.10 CATASTROPHIC ERROR HANDLER 


5.10.1 Catastrophic Error Handler - General Description 





This routine is entered whenever an unrecoverable error is dis- 
covered by HASP. The operator is informed of the error and given 
an error code, and the system enters a one instruction disabled 
loop. The error codes and their meanings are listed in the HASP 
Operator's Guide (see Section 11). For more information, refer 

to Section 9.10.1. 





5.10.2 Catastrophic Error Handler ~ Progra 


ue 
4 


“When this routine is entered, register "RO" contains the address 

~ Of a four byte field containing the three character error code 
left justified. After the system is disabled, the four byte error 
code field is moved into the operator message. This message is 


/ then written on the operator's console defined by the HASPGEN 
ae parameter "SPRICONA": 


S HASP SYSTEM CATASTROPHIC ERROR. CODE = xxx 


After this message is typed, all registers are restored so that 
they. will be intact, and a one instruction loop is executed. 
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5.11 TRACE EFFECTOR 


5.11.1 Trace Effector — General Description 


The Trace Program is a debug facility used in HASP which is completely 
independent of the OS trace facility. This program will insert the contents 
of the general purpose registers into a special trace table (assembled into 
the HASP module) each time it is called and thereby aid in the determin- 


ation of HASP problems. 


5.11.2 Trace Effector — Program Logic 


The Trace Program is called by any Routine or Processor in HASP 
by the insertion of a $TRACE macro-instruction (see Section 9.9.1). If the 
HASPGEN parameter "& TRACE" is set non-zero, the macro-instruction 
will expand into an instruction which will cause a unique specification pro- 
gram interrupt. All program interrupts are fielded by the HASP Trace 
Program and the instruction which caused the interrupt is tested to deter- 
mine if it is the unique instruction inserted by the $TRACE macro-instruction. 
If the interrupt was caused by a true program interrupt, the request is sent 


to the first level interrupt handler, to be handled in the ncrmal way. 


Otherwise a sixteen word trace entry is inserted into the HASP trace table. 
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The sixteen word trace entry has the following format: 
First Byt€....eeeccecsseceeee sd TRACE count 
First Word...cccccccseecveces eS TRACE storage location 
Second Word..ccccccece _ -.. eRegister 0 
Third Word. ...cccscccccccceeo Register l 
Fourth Word...-ceccccccccees eREgiSter 2 
FAL: WONG oiie.s @ereraae ewe ewe eCO Teter 3 
Sixth Word. .csccsccsccescees REGister 4 
SEVENUN: WON secs wo ace sited ee aca Peaister 9 
Eighth Word....scccvcescceeee REGiSter 6 
Ninth WOrdsc0is4-s0ew bee eerwe ss REGISter 7 
Tenth Word. .cccccccccececces register 8 
Eleventh Word...ccosccosoesceee Register 9 
Twelfth Words 10169 ses4e0e0s. Register 10 
Thirteenth Word.........e.-.-. Register 12 
Fourteenth Word.....sceeceees Register 13 
Fifteenth Word......e+eeee-.-Register 14 
Sixteenth Word....cseseeoveceee REGISter 15 
After the trace table entry has been inserted and the pointers updated, 
the count of the number of times this particular $STRACE macro-instruction 


has been executed is inserted into the first byte of the first word of the 
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the trace entry and also into ii last half of the $TRACE "instruction." 
All registers are then restored and return is made by loading the Program 
Old PSW which restores the condition code to its original value before 
the STRACE macro-instruction wae executed. 

The symbolic location "S$ TRACETB" in HASP identifies a three- word 
table with the isiiowing format: the first word is the address of the 
last entry which was made in the trace table; the second word is the 
address of the first byte of the trace table; and the third word is the 


address of the last byte of the trace table + 1. 
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5.12 WTO/WTOR PROCESSING ROUTINE 


5.12.1 WTO/WTOR Processing Routine — General Description 


The function of this routine is to process all OS WTO's and WTOR's. 
If a console buffer is not available for the message the reque shiny task is 
placed in an OS WAIT state until a buffer becomes available to process 
the request. This routine is not included if the HASP interface to OS Console 


Support is generated (SG NUMCON=0, see Appendix 12.15). 


5.12.2 WTO/WTOR Processing Routine — Program Logic 





The WTO/WTOR Processing Routine is entered from the OS Execu- 
tion Control Processor whenever an SVC 35 or SVC 36 is issued. Upon 
entering, a test is made to determine if a free a buffer is available. 
If none are available the user is made to WAIT using the first word of his 
calling sequence as an ECB. The information necessary to later dispatch 
the task is saved in an entry in the SWTORQUE (see figure 5.12.1). 

If an unused buffer exists register zero is set with the parameters 
required by the Console Buffering Routine (see figure 5.13.1), register 
one is set with the message address, and if a job number exists for the 


job, register 10 (JCT) is set with the JCT address. If the SVC represents 
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a WTOR, a reply number is established and a WTOR Reply Element 

(see figure 5.12.2) is set up to service the subsequent operator reply. 
A link is then made to the Console Buffering Routine to initialize 

the buffer with the message. Upon return, HASP is POSTed and the 


processing routine exits to the OS dispatcher via register 14. 
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Figure 5.12.1 -- WTO/WTOR TASK WAIT ELEMENT 


Displacement 


Hex. Dec. 





0 0 
Address of Next’Task Wait Element 
4 4 
Address of User's WTO(R) 
_ Reply Wait 
8 8 
Address of Task Control Block 
Cc 12 
User Parameter List Save Area 
10 16 
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Figure 5.12.2 -- WTOR REPLY ELEMENT 


Hex. Dec. 


Displacement - 





0 0 
Address of Next WTOR Reply Element 

4 4 

Reply Number Address of Event Control Block 
8 8 
Address of Task Control Block 

C 12 
Reply Length Address of Reply Area 

10 16 
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CONSOLE BUFFERING AND QUEUING ROUTINES 


The ee routines are responsible for the queuing and 


de-queuing of all console and log messages. 


CONSOLE BUFFERING ROUTINE - PROGRAM LOGIC 


The Console Buffering Routine is used to prepare a message 
buffer with the information required to process a console 
message. At entrance registers zero and one contain ane infor- 
mation shown in figure 5.13.1. 


The ‘routine makes use of three tables comprised of one-byte 


entries. The bits in each byte specify the physical consoles 


which are to be used for the respective entry. In the first 
(SWCONTBL) each byte corresponds to one of eight consoles. 
The bytes are ORed for each specified symbolic console to 
set the physical byte for a write operation. 


A second table (SWCLASTB) has an entry for each of the six- 
teen possible message classes. The appropriate byte is ANDed 
with the physical consoles byte to screen out consoles with 
the class set too high. 


In addition to setting the console routing byte, the Console 
Buffering Routine supplies the other information shown in 
figure 8.4.1. Prior to returning to the caller, the routine 


_places the message in the log queue (non-HASP messages with 





a job number), or in the queue of messages to be processed 
by the Console Input/Output Processor (all other output 
messages and all reads). 


CONSOLE QUEUING ROUTINE — PROGRAM LOGIt 


This routine places a console buffer into a queue of messages, 
according to priority, to be processed by the Operator Console 
Input/Output Processor and S$POSTs that processor. 


LOG QUEUING ROUTINE — PROGRAM LOGIC 





This routine places a console buffer at the end of the queue 
of messages to be processed by the HASP Log Processor and 
SPOSTs that processor. 


Console Buffering and Queueing Routines - Page 5.13-1 


266 


HAS P 


5.13.4 CONSOLE BUFFER FREEING ROUTINE - PROGRAM LOGIC 


This routine places the console buffer in the free queue. 
The Attention Processor's PCE is examined to determine if 
the Attention Processor is $WAITing for a console buffer, 
and if it is, the Attention Processor is $POSTed and exit 
is made. If the Attention Processor is not $WAITing, the 
SWTORQUE is tested and the first task found is POSTed. If 


no tasks are waiting, the HASP Event Control Field is $POSTed 
and exit is made. 
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Figure 5.13.1 -- CONSOLE BUFFERING ROUTINE PARAMETER REGISTERS 


Displacement 


Hex. Dec. 


San pemeametedl 





0 0 
Consoles Message Priority 
Specified Length & Class 
4 4 
Message Address (or Zero for Read) 
8 8 
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5.14 INPUT/OUTPUT ERROR LOGGING ROUTINE 


5.14.1 Input/Output Error Logging Routine -- General Description 


This routine is entered whenever an unrecoverable Input/Output error 
occurs on a HASP direct-access intermediate storage device, or whenever 
line errors occur which may require the attention of the operator. A 
message is generated describing the error and this message is routed to 
the operator via the operator's console. The routine then returns without 


taking any further action. 


9.14.2 Input/Output Error Logging Routine — Program Logic 


When this routine is entered, register "Rl" contains the address of 
the Input/Output Block (IOB) which is associated with the Input/Output 
operation in error. The channel statue, channel command code, sense 
information, track address, and line status are retrieved from the IOB 
and formatted; the unit address and volume serial are obtained from the 
Unit Control Block (UCB); the device name (if applicable) is acquired 
from the Device Control Table (DCT); and the message is written to the 
operator's console. 

The format of the message describing a direct-access error is as 


follows: 
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I/O ERROR ON SPOOLnuuu,cc,ssss, iiii, bbcchhr _ 


where: 
nN == identifies the SPOOL disk in error 
uuu — unit address of disk 
cc - - channel command code being executed | 
ssss | — channel status code 
iiii — unit sense information 
bbcchhr — track address as follows: 
bb — _ bin (always zero) 
cc -— cylinder 
hh -— head 
r — record 


The format of the message describing a line error is as follows: 


I/O ERROR ON LINEm'__uuu,cc,Ssss, iirr,ttee 


where: 
m — line number 
uuu — unit address of line 
cc | — channel command code being executed 
ssss — channel status code 
ii — unit sense information 


Input/ Output Error Logging Routine — Page 5.14-2 


270 


HASP 


where: 


rr 


tt 


ee 


— STR - sense information 

BSC - terminal response 
— internal sequence and command code 
~— STR - always blank 


BSC - expected response 
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5.15 REMOTE TERMINAL ACCESS METHOD (RTAM) _ 


5.15.1 Remote Terminal Access Method -- General Descrip tion 


The Remote Terminal Access Method provides an interface between the 
HASP Processor and the Remote Terminal. RTAM provides blocking/deblocking, 
compression/decompression, and synchronization with the remote terminal 
in such a way that the processor need not be concerned with the character- 
istics of the remote with which he is communicating. The MULTI-LEAVING 
Line Manager synchronizes very closely with RTAM through a series of 
subroutines, the more important ones, of which, are briefly described 


below. 


-5.15.2 Remote Terminal Access Method -- Program Logic 


The Remote Terminal Access Method consists of four main sections 
and some miscellaneous subroutines. This section discusses the four 
main sections: OPEN, GET, PUT, and CLOSE. The primary subroutines 


are discussed in Section 5.15.3 below. 
OPEN 


The OPEN routines convert the line from an idling mode of operation 
to a transmit or receive mode of operation. In the case of the MULTI- 
LEAVING interface, this routine also generates the request or permission 


to begin a new function. 


Remote Terminal Access Method -- Page 5.15-1 
272 


The GET routines convert data received from the line into EBCDIC 
images suitable for processing by the HASP processors. This conversion 


includes deblocking, decompression, and conversion from line code to 


EBCDIC. 


PUT 
The PUT routines convert data from EBCDIC into a form ready to be 
transmitted to the remote terminal. This conversion includes compression, 


blocking, and conversion from EBCDIC to line code. 


CLOSE 
The CLOSE routines convert the line from a transmit or receive mode 


of operation to an idling mode of operation. 


5.15.3 Remote Terminal Access Method -- Subroutines 
This section describes the primary subroutines used by the Remote 


Terminal Access Method and the MULTI-LEAVING Line Manager. 


MSIGNON ~-- Sign-On Card Processor 


This subroutine is passed the address of a /*SIGNON card in register 
"R11". If the line from which the Sign-On Card was read was defined to be a 
"leased" line, the Sign-On Card is ignored and the subroutine returns immed- 
iately. If the line is a "dial" line, the MABORT and MDISCON subroutines 


are called to disconnect any other remote which may have been attached to 
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this line. The password is then checked and if not valid, an error message 
is issued and the subroutine returns. If the aaeeuene is valid the specified 
Remote Terminal's DCT's are located and examined. If the specified remote 
is already attached to another line or if the specified eos is not locatable, 
the subroutine issues an error message and returns. Otherwise, the specified 


remote is attached to the line and a confirmation message is issue. 


MCCWINIT -- Channel Command Word Sequence Setup Subroutine 


This subroutine is passed a sequence type in bits 24-27 of register 
"RIL". The subroutine then constructs a CCW chain based upon this value 
and returns. Figure 5.15.1 depicts the various CCW sequences which can 


be constructed by the subroutine. 


| MINITIO -- MULTI-LEAVING Input/Output Interface 

This subroutine analyzes the status of a MULTI-LEAVING Remote Terminal 
and takes appropriate action to minimize degradation while insuring maximum 
line throughput. The subroutine first establishes the status of every pro- 
cessor currently active on the MULTI-LEAVING line. Then, based upon the 
active input processor count, the active output processor count, the status 
of the remote terminal, and the status of input and output buffers queued 
within HASP either transmits an ACKO to the terminal, transmits a text buffer 


to the terminal, or initiates a one-second delay. 
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MEXCP -- Remote Terminal Input/Output Interface 


This subroutine interfaces the Remote Terminal Access Method with 
the standard HASP "SEXCP" Input/Output Interface. In addition to initiating 
I/O, this subroutine also provides the MULTI-LEAVING Block Control Byte 


sequence count, and the BSC 2770/2780 parity check (ACKO-ACK1) 


conversion. 
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Figure 5.15.1 — HASP Remote Terminal CCW Sequences 


STR Hardware Terminal Prepare Sequence (code = 4) 





INTERNAL 
CCW COMMAND DATA ADDRESS -— FLAGS CODE § BYTE COUNT 
IOBCCWL DISABLE 0 60 40 | 1 
IOBCCW2 SET MODE LCBMCB 60 41, 2 
IOBCCW3 ENABLE 6) 60 42 1 
IOBCCW4 TEST SYNCH 6) 60 43 15 
LOBCCWS SEND INQUIRY 0 20 4A 6 
STR CPU Terminal Prep 
INTERNAL 
CCW COMMAND DATA ADDRESS FLAGS CODE BYTE COUNT 
IOBCCW2L DISABLE 0 60 50 1 
IOBCCW2 SET MODE LCBMCB 60 51, 2 
IOBCCW3 ENABLE | 0 60 52 1 
IOBCCW4S TEST SYNCH 0 60 53 15 
IOBCCW5 SEND EOT 0 60 _ 5B 6 
IOBCCW6 PREPARE 0 60 57 1 


IOBCCW7 READ TPBUF ST 20 54 &TPBFSIZ 
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Figure 5. 15.1 (continued) — HASP Remote Terminal CCW Sequences 


STR Read Sequence (code=0: Hardware; code=1: CPU). 


| INTERNAL 

CCW COMMAND DATA ADDRESS = FLAGS. CODE BYTE COUNT 
IOBCCWL = TEST SYNCH 0 60 03/13 15 
IOBCCW2 § PREPARE 0 60 07/17 1 
IOBCCW3 READ TPBUFST 20 04/14 ETPBFSIZ 
IOBCCW4 = STEP COUNT 0 60 00/10 1 
IOBCCWS ERROR 0 60 00/10 — 1 


TOBCCWG TIC IOBCCW3 00 00/10 0 





| INTERNAL | 
CCW COMMAND DATA ADDRESS FLAGS CODE BYTE COUNT 
LOBCCWL TEST SYNCH | 0 60 23/33 45 
IOBCCW2 SEND INQUIRY 0 60 2A/3A 6 


IOBCCW3 WRITE TPBUFST 20 28/38 pi 
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Figure 5.15.1 (continued) — HASP Remote Terminal CCW Sequences 


BSC Prepare Sequence (code =C) 





INTERNAL 
CCW COMMAND DATA ADDRESS FLAGS CODE BYTE COUNT 
IOBCCWL DISABLE 0 60 CO 1 
IOBCCW2 SET MODE LCBMCB 60 C1 1 
IOBCCW3 = ENABLE 0 60 C2 1, 
IOBCCW4 NOP MBSCSYN 60 CA 4 
IOBCCWS5 = NOP/WRITE MBSCENQ/MBSCEOT 60 CA 1, 
IOBCCW6 READ LCBRCB 20 C6 2 
INTERNAL 
CCW COMMAND DATA ADDRESS = FLAGS CQDE BYTE COUNT 
IOBCCWL = ENABLE 0 60 92 1, 
IOBCCW2 NOP MBSCSYN 60 99 4 
IOBCCW3 WRITE LCBRCB 60 99 2 
IOBCCW4 READ TPBUFST 20 94 &TPBFSIZ 
IOBCCW5 —- NOP MBSCSYN 60 98 4 
IOBCCW6 = WRITE TPBUFST 60/A0 98 2k 
IOBCCW7 =: WRITE METBSEQ 60 98 2 


IOBCCW8 READ TPBUFST 20 Bo &TPBFSIZ 
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Figure 5.15.1 (continued) — HASP Remote Terminal CCW Sequences 


BSC Hardware Terminal Read Sequence (code = 8) 


INTERNAL 
CCW COMMAND DATA ADDRESS — FLAGS CODE BYTE COUNT 
IOBCCW1 ENABLE 0) 60 82 1 
IOBCCW2 NOP MBSCSYN 60 89 4 
IOBCCW3 WRITE LCBRCB 60 89 2 
IOBCCW4 READ TPBUFST 20 84 &TPBFSIZ 
BSC Hardware Terminal Write Sequence (code =A) 
INTERNAL 
CCW COMMAND DATA ADDRESS _ FLAGS CODE BYTE COUNT 
IOBCCWL ENABLE 0 60 A2 1 
IOBCCW2 NOP MBSCSYN 60 AA 4 
IOBCCW3 WRITE MBSCENQ 60 AA 1 
IOBCCW4 = READ LCBRCB =—s—‘ié2O A6 2 
IOBCCW5 NOP , MBSCSYN 60 A8 4 
IOBCCW6 WRITE TPBUFST 60 A8 ek 
IOBCCW7 WRITE METBSEQ 60 A8 2 
IOBCCW8 READ LCBRCB 20 AS 2 
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5.16 OVERLAY SERVICE ROUTINES 


5.16.1 Overlay Service - General Description 


These routines, together with the Overlay Roll Processor des- 
cribed in Section 4.20, respond to calls from other HASP Processors 
when the macros $LINK, $LOAD, $XCTL, S$RETURN, and $DELETE are 
executed in HASP coding. This enables certain executable and table 
portions of HASP coding (assembly control sections created by use 
of the SOVERLAY macro) to be brought into main storage from their 
normal direct access residence for use during HASP execution. 


Major objectives of Overlay Service and Roll logic are: to allow 
multiple Processors to use a single copy of the same overlay routine 
Simultaneously, and to prevent any system lockout due to SWAITs in 
overlay routine coding. 


The overlay data set is constructed as part of HASP installation 
by the HASP Overlay Build utility, described in Sections 10.2.2 
and 6.3, and is referred to by the ddname OLAYLIB in the job which 
invokes HASP. | 


All Overlay Service and Roll Processor coding is located in module 
HASPNUC. Service entry points are addressable by register BASE] 
and are referenced by macro expansions through the HASP Communica- 
tion Table. 


Actions necessary to initialize HASP Overlay Service are contained 
in module HASPINIT and are described in Section 6.1.2. 


See Sections 8.3.3, 9.7, and 12.14 for descriptions of Overlay | 
Area(s) format, macros mentioned above, and coding rules relating 
to use of overlay routines. 


DelO2 SLINK Service - Program Logic 


On entry, register "R15" contains the address of the next instruc- 
tion after $LINK and register "LINK" contains the called routine's 
Ocon. An Ocon is an index into the HASP Overlay Table, which is 
the control section HASPOTAB created by the HASP Overlay Build 
utility, whose individual entries are defined in OTBDSECT, created 
by the SOTB macro. 


The calling Processor's registers "RO-WC" are saved in the caller's 
PCE. Overlay Service base address is established in register "WC". 
Register "R15" is saved in PCEORTRN. "R15" is set to the relative 
displacement of the called routine entry point from the beginning 
of an Overlay Area IOB, i.e., OACEPROG-BUFDSECT. The called 

routine Ocon is saved in PCEOCON, then used to compute the address 
of the Overlay Table entry for the called routine. If &DEBUG is set 
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to YES, field OTBCALLS is incremented by one. The called routine's 
priority is moved to PCEOPRIO. 


If the Overlay Table indicates that the called routine was made a 
permanent part of the HASP Load Module at Overlay Build time, 
register BASE3 is loaded with the address of a theoretical Overlay 
Area containing the resident routine (BUFSTART-BUFDSECT bytes prior 
to the routine itself), caller's "RO-WC" are reloaded, and control 
is passed to the called routine at its entry point. 


If the called routine is not permanently resident, a search is made 
of all Overlay Areas in the system. If the called routine is found 
in an area (PCEOCON equal to area's OACEOCON), the caller's PCE is 
added to the chain of all active users of the area. This chain 
begins at OACEPCE and continues through PCEOPCE of each PCE, if 
several users are on the chain, and ends with a zero chain word. A 
test is made for illegal nested S$LINK if &DEBUG is set to YES, see 
Operator's Guide for error message. If the called routine is in 
process of being read into the area from direct-access, the calling 
Processor is made to SWAIT on OLAY, to be later activated by the 
Overlay SASYNC Exit (see 5.16.9). Otherwise, caller's "RO-WC" are 
reloaded and control is passed to the called routine entry point, 
with register BASE3 containing the address of the Overlay Area IOB 
for use as the overlay routine base address. 


If the called routine is not found while searching all Overlay Areas, 
the search attempts to find an Overlay Area which is not currently 
in use. It may contain an overlay routine but may not have active 
users (OACEPCE must be zero). The inactive area containing the rou- 
tine of lowest priority (OACEPRIO) will be used, subroutine OLOD 

(see 5.16.8) will be called to start reading the called routine from 
direct-access, and the calling Processor will be SWAITed on OLAY, 

to be later activated by Overlay SASYNC Exit (see 5.16.9). 


If no inactive areas are found, the calling PCE is placed on a Queue 
waiting for an Overlay Area. The Queue begins at the word SWAITACE, 
continues in descending priority order by PCEOPRIO using chain word 
PCEBASE3, and ends with a zero chain word. If several PCES are on 
the Queue requesting the same overlay routine (PCEOCONsS equal), only 
the first PCE is on the above chain, the others are chained from it 
using word PCEOPCE. All PCEs in the Queue are SWAITed on OLAY. 

This Queue is emptied by the Overlay Roll Processor, as described in 
Section 4.20, or by the OEXIT subroutine, as described in 5.16.7. 


Overlay Service Routines - Page 5.16.2 


281 


HAS P 


5.16.3 SLOAD Service - Program Logic 


SLOAD shares almost all logic with S$LINK (see 5.16.2). Entry 
register conditions are identical to those for $LINK. 


"R15" is not saved in PCEORTRN. "R15" is not set to the relative 
entry point of the called routine. 


When the called routine is found in an Overlay Area or read into 

one by later system actions, "R15" still contains the address of 

the next instruction after SLOAD. Subsequent use of "R15" as an 
absolute entry point results in control being returned to the caller 
with the routine in an actual or theoretical area, addressable by 
BASE3 as with S$LINK. 


5.16.4 $XCTL Service - Program Logic 


SXCTL logic shares almost all logic with SLINK (see 5.16.2). Entry 
register conditions are identical to those for $LINK. 


"R15" is not saved in PCEORTRN. S$XCTL is legai only when it logi- 
cally follows another $XCTL or an original SLINK. Subsequent 
SRETURN uses PCEORTRN as stored by the original SLINK to return 
control from Overlay Service to the original caller. 


Before doing entry actions for the new called overlay routine, the 
OEXIT subroutine is called (see 5.16.7) to remove the calling 
Processor's PCE from the chain of users of the current overlay 
routine. | | 


5.16.5 SRETURN Service - Program Logic 


On entry, register LINK points to the next instruction after SRETURN 
and also contains the condition code and program mask as set by a 
BAL instruction. BASE3 points to an actual or theoretical area con- 
taining the current overlay routine. 


Caller's "RO-WC" are saved in the PCE. Overlay Service base address 
is established in WC. 


The OEXIT subroutine is called (see 5.16.7) to remove caller's PCE 
from the chain of users of the current overlay routine. 


Returned condition code is re-established using an SPM instruction. 


Caller's "RO-WC" are reloaded. Control is returned to the address 
previously saved in PCEORTRN by $LINK. 
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5.16.6 SDELETE Service - Program Logic 


SDELETE is nearly identical to SRETURN, except that it is used to 
release control of an overlay routine previously SLOADed. 


On entry, register LINK points to the next instruction after SDELETE. 
This is stored in PCEORTRN. and all actions described for $RETURN 
are performed. 


5164-7 < OEXIT Subroutine - Program Logic 


This subroutine is used by service routines for $XCTL, SRETURN, and 
SDELETE to release use of the current overlay routine by the calling 
Processor. On entry, register WA contains the subroutine return 
address and register BASE3 contains the address of an actual or 
theoretical (permanently resident routine) Overlay Area containing 
the current overlay routine. 7 


If the current overlay routine is permanently resident, OEXIT returns 
immediately. Otherwise, the chain of all users of the area (begin- 
ning at OACEPCE and continuing through PCEOPCE) is searched and the 
caller's PCE is removed. If other Processors are still using the 
area, OEXIT returns. "34 


If the above actions result in the Overlay Area becoming inactive 
(OACEPCE equal zero), the SWAITACE Queue (see 5.16.2) is inspected. 
If PCE(s) are waiting, the top priority group of one or more request- 
ing the same overlay routine is de-queued, the address of the first 
such PCE is placed in register "R1", and OEXIT simply falls through 
to the OLOD subroutine (5.16.8), which eventually returns to the 
caller of OEXIT. | 


5.16.8 OLOD Subroutine - Program Logic 


This subroutine is used by service routines for SLINK, $LOAD, SXCTL; 
by the Overlay Roll Processor (see Section 4.20); and indirectly 

by users of the OEXIT subroutine (5.16.7). Its purpose is to start 
a read for a requested overlay routine from the direct-access device 
containing the overlay data set. On entry, register WA contains the 
subroutine return address, register BASE3 contains the address of an 
actual Overlay Area to be used, and register "Rl" contains the ad- 
dress of the first of a group of one or more PCES requesting the 
same overlay routine, chained from the first PCE by PCEOPCE. 


OACEPCE of the Overlay Area. is pointed to the first PCE. OACEPRIO 
and OACEOCON are set to indicate the routine which will reside in 
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the area. The Overlay Table entry for the requested routine is 
accessed and, if &DEBUG is set to YES, field OTBLODS is incremented 
by one. 


The relative T and R in the overlay data set of the requested 
routine is obtained from the Overlay Table. The address of the 
Overlay DCT is loaded into register "Rl". If the overlay data set 
is on any SPOOL volume (device type DA in the DCT), an absolute 
form of MTTR is computed and stored in DCTSEEK. This conforms to 
SEXCP requirements for SPOOL volumes (see 5.8) and allows SEXCP to 
remember SPOOL arm positions. If the overlay data set is ona 
non-SPOOL direct-access volume, the standard OS form of MBBCCHHR 

is computed and stored in IOBSEEK. See Section 6.1.2 for initiali- 
zation of the Overlay DCT and data set. | | 


Hardware read operation is requested by using the SEXCP macro. The 
Overlay DCT specifies that when the read operation is complete, 
Overlay SASYNC Exit is to be entered. All PCEs chained from 

OACEPCE are already SWAITing OLAY, to be later activated by Overlay 
SASYNC Exit (see 5.16.9). OLOD then returns to its caller or caller 
of OEXIT. 


5.16.9 Overlay SASYNC Exit - Program Logic 


This routine is entered when under control of the Asynchronous Input/ 
Output Processor (S$ASYNC) PCE (see Section 4.8) an overlay read opera: 
tion (started by OLOD subroutine, see 5.16.8) is posted complete. 
On entry, register "Rl" points to the Overlay Area. BASE2 is set 
to the base value for the Overlay Roll Processor, which is used for 
local addressability. "R15" contains the return address to SASYNC. 


The chain of all users of the overlay routine just read (begins at 
OACEPCE, continues through PCEOPCE) is processed. Each PCE's 
re-entry address ("R15", now stored in PCER15) is absolutized by 
adding the address of the Overlay Area, if the value in PCERL5 is 
determined to be relative. The address of the Overlay Area is also 
stored in each PCEBASE3, to provide addressability when the Dis- 
patcher activates each Processor. The function SPOST for OLAY is. 
performed on each PCE to make it dispatchable. 


If OS IOS has posted the read complete with a permanent I/O error, 
each PCE's (on OACEPCE chain) re-entry address (PCER15) is pointed 
to a routine which types the message "UNREADABLE OVERLAY - ..." 
and enters a permanent S$WAIT. The Overlay Area is freed for other 
use. | 


If &OREPSIZ is set to zero, this Exit returns to SASYNC. Other- 
wise, the Overlay REP storage area is examined to see if any REPs 
were read during HASP Initialization (see 6.4) which may apply to 
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this overlay routine. REPs whose CSECT name (last four characters) 
match OACENAME are applied. The assembly origin (OACEASMO) of the 
routine is subtracted from the REP address and the BUFSTART address 


of this Overlay Area is added, to determine the memory location to 
be patched. 


Return is finally made to SASYNC to allow other processing to con- 


tinue. The Dispatcher will enter each Processor using the overlay 
routine just read. 
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6.1 HASP INITIALIZATION 
6.1.1 HASP Initialization - General Description 


The purpose of HASP initialization is to initialize for HASP job 
processing. Initialization builds the required control blocks and 
makes modifications to the Operating System nucleus which allows 
HASP to monitor the execution of jobs. 


HASP Initialization is designed to provide either a "cold" or "warm" 
Starting capability. A "cold" start is one which starts the system 
anew. Only those jobs which are entered after a "cold" start will 
be processed. A "cold" start does not have any requirements as to 
configuration except as defined in the HASP generation parameters. 
A “warm" start is a restart. Checkpointed information is read from 
the SPOOL1 volume and the queued jobs and data from the last pro- 
cessing are recovered. This type of start requires, as a minimun, 
that the SPOOL volumes that were used during the previous execution 
be on-line. Extra SPOOL volumes, up to a total of &NUMDA volumes, 
may be added. 


Cidiecd HASP Initialization - Program Logic 


Initialization begins with the issuing of the HASP Supervisor Call 
which turns control over to the HASP Initialization SVC Routine. On 
return the HASP task will be in the Supervisor State with protect 
key of zero. Register 1 points to a list of resolved nucleus 
addresses and a return point for resetting HASP to problem state. 
These addresses are moved into the HASP Communication Table (HCT) 
for later use by the system. 


Since HASP Initialization resides in the same area as the main HASP 
buffer pool as designated by the HASP parameter &NUMBUF and portions 
of the initialization routines are executed from overlay control 
sections, all HASP processors except those required for initiali- 
zation and console processing are placed in the hold status. The 
command processor PCE is altered to refer to the Root Segment of 
HASP Initialization, which resides in the data portion of the 

first buffer used for HASP SPOOLING. The HASP Initialization WTOR 
is then displayed via OS WTOR facilities. Initialization then waits 
for the operator to respond with the desired options. The options 
are then compared against the Initialization Options table and the 
appropriate bits in the SOPTSTAT field in the HCT are set or reset 
in accordance with the options specified. If any option is incor- 
rectly entered, an error message is issued and the SOPTSTAT field 

is set to the default option configuration. (Refer to STARTING THE 
HASP JOB Section of the HASP Operator's Guide.) 
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The HASP REP routine (described in Section 6.4) 1s entered for 
optional alteration of the resident portions of the Operatiny 
System or HASP (resident or overlay control sections). 


Preparation Of Overlay Service 


The Overlay DCT is prepared by indicating that it is in use, 1s 
only for reading, that Overlay SASYNC Exit is to be entered on 
completion of any operation which was started by using Overlay 
DCT, and that Overlay Roll Processor is the owner of the DCT. 


The overlay data set is described by a DD card having ddnane +! 
OLAYLIB. DEVTYPE and OPEN macros are used to determine the num- 
ber of tracks/cylinder of the overlay volume and data set exteni. 
which is placed as the last (s&NUMDA+1) extent in HASP's single 
muiti-extent direct-access DEB. The overlay data set is closed 
Since HASP uses its own constructed I/O control blocks. 


The overlay data set UCB address is stored in a table used to 
withdraw or abort HASP and the UCB is made allocated, permanent: 
resident, and private. 


The number of tracks/cylinder and extent are used to compute a 
beginning absolute TT of the overlay data set, which is stored 
in the Overlay DCT for later use by the OLOD subroutine (see 
Section 5.16.8). 


Locating Spool Volumes 


All OS UCBs are searched via the UCB lookup table and direct-acor 
volumes with volume serials of SPOOLx are examined for use for HA 


SPOOL volumes. As each device is examined, the UCB is allocated 
by turning on the private, reserved, permanently resident, and 
allocation indicators. The UCB locations and sixth volume serial 
character are saved in a temporary workarea for later reference. 
If during the UCB search multiple volumes with the same serial 

or too many SPOOLx volumes are found, an error message is display 
SPOOL volume UCBs are deallocated and the HASP job is terminated. 
Upon completion of a successful allocation of SPOOL volumes, con- 
trol is passed to Direct-Access Initialization. 


HASP Initialization - Page 6.1.2 


289 


sal ’ 
a 


q \- 


see 





HAS P 
Direct-Access Initialization 


Direct-Access Initialization (NGDAINIT) gains control after all 
Spool devices have been found by initialization; initialization has 
built a table of six-byte entries (NSPOOLL1) describing the direct- 
access devices upon which Spool disks are mounted, of which each 
entry appears as follows: 


od Bie 


where: 





dev is the low-order byte of the direct-access 
device type; 


vol is the low-order byte of the volume serial 
number; and 


UCB is the device's UCB address. 


Before checking for warm start, NGDAINIT establishes where the 
checkpoint record is to be placed on SPOOL]. To do this, it first 
calls the DEB/TED setup routine to establish certain statistics 
about all mounted Spool volumes and then issues an OBTAIN macro- 
instruction for SYS1.HASPACE on SPOOL]. The checkpoint information 
will reside on the first track of this data set (the first two 
tracks if &JITSIZE is not zero); accordingly, NGDAINIT sets up 

the necessary channel programs uSing the OBTAINed information. 


WARM START 


If the operator requested a warm start, NGWARM reads the checkpoint 
information directly into the area from which the checkpoint 
processor will write it; the information consists of the HASP job 
queue, the track group map, printer checkpoint information, mis- 
cellaneous status information (including direct access checkpoint 
information) and, optionally, the job information table (JIT). 

The direct access checkpoint information, S$DACKPT, consists of 
&NUMDA six~-byte entries of the following form: 


1 Ca 4 


dev is the low-order byte of the direct-access device type; 


0 








where: 
vol is the low-order byte of the volume serial number; 
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ssss is the starting absolute track number of data set 
SYS1.HASPACE on the indicated SPOOL volume; and 


eeee is the ending absolute track number of the first 
extent of data set ‘Sysil. HASPACE on the indicated 
SPOOL volume. 


For SPOOL1, the starting track number excludes the checkpoint 
tracks. 


NGWARM insures that each volume specified in the direct-access 
checkpoint is mounted and, with the help of subroutine NGALLOC, 
that its extents are unchanged. If not all volumes are mounted, 
or if any extents have been changed, or if a cursory check of 

a volume shows that it is not properly formatted, NGWARM writes 
a message and sets a quit switch to cause HASP to quiesce. 


T£ all volumes specified by the direct~-access checkpoint are 
correct, NGWARM checks for (and formats if necessary) newly- 
mounted volumes. Then it again calls subroutine NGDEBSET to 

allow for the possibility that the order of Spool volumes in 
NSPOOLL1 (by unit address) may not have been the same as in SDACKPT; 
the final order is that of SDACKPT. 


Now NGWARM relocates the HASP job queue, if necessary. The job 
queue as recorded in the checkpoint record contained main storage 
addresses; if HASP does not now occupy the same core locations as 
it did before, each main storage address in the HASP job queue (and 
in pointers to the job queue) must be adjusted to reflect the cur- 
rent main storage location of the job queue. 


After relocation, NGWARM scans the job queue to check the busy bit 
of each active entry and to reset certain flags. If a busy bit is 
on, NGWARM turns it off and issues a WTO to inform the operator 
that the job was reading, executing, printing, or punching. Addi- 
tionally, if the job was reading, NGWARM uses HASP queue manage- | 
ment routine SQREM to delete the job's queue entry. 


At the end of the job queue, NGWARM gives control to NGEXIT, 
which assembles and format-writes the checkpoint information; 
restores the HASP appendage table pointer in SDADEB1, the HASP 
multi-extent direct access DEB; counts the number of allocated 
track groups (one-bits) in the track group map; and gives control 
to NINITWTO. sje 

‘ae 


COLD/FORMAT START + 


If the operator specified cold or format start, NGCOLD first zeros 
out the track group map. Then NGCOLD processes each mounted SPOOL 
volume. a 
ee | 

For each volume, NGCOLD uses subroutine NGALLOC to process the DSCB 
for SYS1.HASPACE. This subroutine issues the OBTAIN macro-instruc- 
tion to retrieve the DSCB; if OBTAIN's return code is not zero, an 
appropriate error message is printed via WIO. If the return code is 
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zero, NGALLOC computes and saves lower and upper absolute track 
numbers. 


If NGALLOC operated normally, NGCOLD now tests for an operator 
specification of COLD; if the test is positive, NGCOLD calls sub- 
routine NGREADCT to read and validate the count field of the first 
record of the last track of the first extent of SYS1.HASPACE on the 
volume. If the count field is invalid, or if the operator specified 
FORMAT, NGCOLD calls NGFORMAT to format the first extent. NGFORMAT 
issues an unconditional GETMAIN for core in which to build a for- 
matting channel program and data, builds them, and formats each 
track by calling NGEXCP, which merely issues an EXCP and a WAIT 

and checks the post code. 


After the volume has been inspected (and formatted if necessary), 
NGCOLD calls NGMAP to calculate the number of track groups in this 
volume and the track group number of the first track group. NGCOLD 
increments the overall number of track groups available for alloca- 
tion by the quantity returned from NGMAP and then calls NGBITMAP 
which turns on in the master track group map the bits corresponding 
to available track groups on this volume. Then NGCOLD processes 
the next volume. 


When all volumes have been processed NGCOLD refreshes. certain 
checkpoint information (the HASP job queue, the print checkpoint 
information, and some miscellaneous checkpoint TR EQENSELOn) and 
gives control to NGEXIT, as above. 


The DEB initialization subroutine, NGDEBSET, initializes certain 
HASP and OS control blocks and allows a great degree of SPOOL 
device independence. 


When called, NGDEBSET first puts into SDADEB]1 the address of the 
HASP TCB; it also changes the DEB appendage address to point to 
the standard IOS appendage. (The appendage address is restored 
by NGEXIT.) It checks for SPOOL1 and quiesces HASP if SPOOL] is 
not found. Then NGDEBSET processes the Spool volumes. 


For each volume, NGDEBSET calculates number of records per track 
using information from the device characteristics table IECZDTAB 
in the OS nucleus and the formula given with the DEVTYPE macro- 
instruction in the OS System Programmer's Guide. Then it sets up 
certain information in an entry of the Table of Extent Data (TED). 


Then, after setting the UCB address in S$DADEB1, NGDEBSET performs 
the same functions for the remaining volumes and returns to the 
caller. 
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Activation of Overlay 


If the overlay data set is contained on a SPOOLx volume, the 
Overlay Device Control Table is adjusted so that SEXCPs done by 
the OLOD subroutine (see 5.16.8) will use MTTR addresses and M 
which refers to the DEB extent for the SPOOLx volume rather 

than the overlay data set extent. The first Processor Control 
Element (PCE) in the HASP chain is connected to the OS save area 
chain and, with register 13 pointing to the first PCE, Initiali- 
zation enters the HASP DISPATCHER as though the first processor 
had executed a SWAIT macro. The HASP DISPATCHER will run the PCE 
chain and dispatch the Initialization ROOT segment. The ROOT 
segment will SLINK to the first overlay control section HASPIOVA. 


Unit Record Initialization -HASPIOVA 


The OS UCBs are scanned for unit record devices. Devices which 
are on-line on a DUAL Processor Model 65 system, have OS 
scheduled I/O activity, or answer positively to a TIO instruction 
are considered real devices. Otherwise the devices are con- 
sidered pseudo devices. 


PSEUDO DEVICE INITIALIZATION - Pseudo. devices are initialized by 
flagging the UCB for later identification by the HASP Execution 
Processor SVC 0 intercept routines and are varied on-line. 


Pseudo 2540 reader, 1442 special forms punch, and 1443 special 

forms printer devices are especially noted and counts are maintained 
for the HASP Execution Processor Device Allocation Routine. Pseudo 
1403 Printer UCS feature is removed from the UCB. Pseudo 2520 
devices are identified and matched with an internal reader INTRDR 
Device Control nae which is initialized for processing. 


REAL UNIT RECORD DEVICE INITIALIZATION - Bach device is matched with 
a corresponding Device Control Table which is initialized for pro- 
cessing. If the device is allocated by OS, the DCT will remain 

in the drained status causing HASP not to use the device unless 

the operator starts the device by command. Automatic starting _ 
reader and (as appropriate) HASP console UCB attention index values 
are set to four allowing HASP to recognize the readying of the 
readers or the pressing of the enter key(s). (At least one HASP 
console device is reserved for a 1052 type of device.) If more 
real unit record devices of each particular type are found than 
available DCTs, an error meesede 1s displayed and the additional 
devices are ignored. 


Control is then passed to the Remote Job Entry or console initiali- 
zation routines as appropriate via a exCTE, macro. 


ae ae = HASP Initialization - Page 6.1.6 





HAS P 


Remote Job Entry Initialization - HASPIOVR 


LINE INITIALIZATION - The OS UCBs are scanned for Synchronous 
Communication Adapter devices. The UCBs found are first matched 
with one or more DCT and corresponding line descriptions (LINEmm 
HASP Generation Parameters). Any DCT with a line description 
which specifically designates the UCB will be initialized for the 
UCB. If no line description designates the UCB, tests are made 

to determine if the adapter is physically on-line and, if so, 

a DCT with a line description with "***" specified will be located 
and initialized. Line devices will not automatically be started. 


REMOTE DEVICE INITIALIZATION - Remote Device Control Tables are 
connected and initialized with information contained in the corres- 
ponding remote description (RMTnn HASP Generation Parameter). Each 
group of RMr.RDn,...,RMr.PRn,...,RMr.PUn,... for a given remote 

are chained together for control by the MULTI-LEAVING-line manager 
and RTAM. In addition the printer and punch DCTs are removed from 
the chain of all HASP DCTs and reinserted directly behind the 
reader DCT for the corresponding terminal. The device description 
is converted to internal flags and placed in each of the corres- 
ponding DCTs. If the line number is designate in the description 
the line DCT is located, DCTs are chained together, and flags are 
set to indicate non-signon remote. 


The HASP Remote Job Entry Buffer Pool is initialized and control 
is passed to the remote console initialization routine or console 
(local) initialization routine as appropriate by $XCTL. 


Remote Console Initialization - HASPIOVS 


The Operator Message Space is allocated and control blocks are ini- 
lialized. The Remote Console Processor PCE and a direct-access DCT 
are connected (the DCT is flagged IN USE). The origin of the first 
available track in the SYS1.HASPACE data set of the SPOOL1 volume 
and the base track address for operator message record allocation 
is set into the MSAMTTR field of the MESSAGE ALLOCATION ($MSALLOC) 
Table in the form: OTT1 (TT is the first track available for 
messages). The number of records per track for the mounted SPOOL1 
volume is inserted into the MSARPTRK field. If "cold" start was 
performed by direct-access initialization, the Cylinder map for 
SPOOL] is altered to reflect the allocation of sufficient adjacent 
track groups starting with the group of the base track. The num- 
ber of the last group is saved in the checkpoint records for 

future "warm" starts. If a "warm" start was performed by direct- 
access initialization, a check is made against the checkpoint record 
to insure that the space required is within the allocated space. | 
Control is given to the console (local) initialization routine 

by $XCTL. 
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Console Initialization - HASPIOVB _ 


OS CONSOLE INITIALIZATION - Information is extracted from the OS 
UCM and the Console processor is made ready for interfacing with 
Os. 


HASP CONSOLE INITIALIZATION - The Console DCTs are initialized 
for HASP console support. Each DCT that was matched with a UCB 
by the unit record initialization routine is initialized for I/O 
processing. The corresponding authorization for each console 

is converted to console restrictions and set into the DCT. The 
Operator command $&S console is simulated. 


Control is passed to the intercept initialization routine via SXCTIL. 


Intercepts Initialization ~ HASPTIOVC 


The following intercepts are made in accordance with the type of 
the HOST Operating System MVT or MFT and the HASP generation 
options as follows: 


SVC 0 - EXCP interface used for control of user I/O 

SVC 6 - LINK interface used to recognize events within OS 

SVC 7 - XCTL interface used to recognize events within OS 
and to interface with OS console support 

SVC 35 - WTO interface for console support 

SVC 36 - WIL interface for write to log support. 


Start Initiator, reader, and writer (optional) commands are issued 
which start the procedures contained on SYS1.PROCLIB. The reader 
will be directed to the pseudo device &RDR and the writer will be 
directed (if started) to the pseudo device &WTR. 


In the event the HASP writer is selected in lieu of the OS writer, 
the HASP writer module "HASPWTR" is attached. If OS console sup- 
port is selected, the HASP communications task is attached, via the 
attaching of module "HASPBR1" which enters the console processor. 


Control is passed to the HASP buffer building routine via $XCTL. 
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Buffer Build - HASPIOVD 


An OS variable GETMAIN is issued to obtain storage for the alternate 
buffer pool from the hierarchy as designated by the &BUFHICH 
generation parameter. The actual amount of core is reduced by the 
amount of reserved core (&RESCORE*1024) and used to determine the 
number of buffers which may be created in the alternate buffer 

pool along with the actual amount of storage needed. Extra core 

if any is released via OS FREEMAIN. The number of buffers which 

may be created in the alternate pool is compared against the 
expression of generation parameters: 


&MINBUF - &NUMBUF where &MINBUF = &NUMBUF = number of buffers 
| in the main buffer 
pool 


If the alternate buffer pool will not contain at least the number 
of buffers specified by the expression a warning is issued. 


The origin of the main and alternate buffer pools are examined to 
determine which has the lower storage address. The pool with the 
lowest address is created and chained to the S$BUFPOOL chain of 
buffers. The pool remaining is then created and chained to the 
end of the first. 3 | 


The operator is then asked to ENTER HASP REQUESTS (optional) and 


the ROOT segment of HASP INITIALIZATION is entered via the SRETURN 
macro. 


Activation Of Normal Processing 


~~. The ROOT SEGMENT returns the PCE to the Command Processor and, if 


the operator specified REQ in the WTOR, enters the Command Proces- 
sor. If NOREQ was specified by the operator, all HASP Processors 
are $POSTed and the Command Processor is entered. 
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Oued HASP INITIALIZATION SVC ROUTINE 

Gu2ed HASP tnitvalieacion SVC Routine - General Description 
This program is a Type-I SVC routine which resides in the Operating 


System Nucleus and provides the following basic functions: 


l. For HASP: 


e To give HASP a zero storage protection key. 

@ To place HASP in supervisor state. 

© To return the address of key symbols in the nucleus 
which are required for HASP processing. 

© To guard against recursive entries in order to prohibit 
multiple copies of HASP from being initiated. 

@ To provide the address of an entry which will cause 


the SVC routine to be reset for HASP withdrawal and 
cause the PSW to be reset to its initial value. 


23 For the HASP Reader/Interpreter Appendage: 
e To place the HASP JCL Exit routine in supervisor 
| state. 
@ To return the left half of the PSW which was in use 
when the SVC was invoked. 
oe For the non-HASP program: 
® To give an indication to any other program as to 


whether HASP is currently active or not. 


6.2.2 HASP Initialization SVC Routine - Program Logic 


This program is a Type-I OS SVC routine. It must be link-~edited 
with the nucleus to resolve the external address constants required 
for HASP processing. 

Upon entry, register 1 is compared with the EBCDIC characters "HASP". 
If the register does not compare, a condition code is returned to 
the user in register 15 as follows: 


R15 = 0 - HASP has not been initiated and is not currently 
active. 


R15 = 0 - HASP has been initiated and is currently active. 
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If register 1 contains "HASP", a test is made to determine if 
HASP has been invoked. If not, then this switch is set to | 

indicate that HASP is now active and the left half of the PSW 

1s saved for the "reset EHenY 


If HASP has been invoked, the protect key of the caller is 
interrogated. If this protect key is non-zero, the caller 
is ABENDed with an appropriate ABEND code. 


The SVC OLD PSW is modified so that the return to HASP will 
place HASP in the supervisor state and give HASP a zero storage 
protection key. Register 1 is then loaded with the address of 

a table of address constants of key nucleus addresses and return 
is made through the OS SVC FLIH. At this time register 0 con- 
tains the left half of the PSW which was in use when the SVC 

was invoked. 


One of the addresses in the nucleus address table is the address 
of the SVC reset routine. When this routine is entered, it | 
resets the switch to indicate that HASP is no longer active. It 
then returns to the user by loading a PSW constructed by con- 
catenating the left half of the original PSW with register 14. 
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6.3 HASP OVERLAY BUILD UTILITY 
6.3.1 HASP OVERLAY BUILD - GENERAL DESCRIPTION 


The purpose of this program is to process the object deck 
output from the ten primary HASP assemblies. Overlay CSECTs 
are extracted and written (each as a single record) to the 
sequential overlay data set (ddname OLAYLIB), all references 
to overlays from resident and overlay routines are resolved, 
and all resident CSECTs (even if programmed as overlayable) 
are passed to the OS Linkage Editor in a sequential data set 
(ddname SYSLIN). Optional control cards are processed which 
allow changing the status of any overlayabie CSECT from actual 
overlay to permanently resident and vice-versa. 


The use of this program to install HASP (control cards, list- 
ings produced, etc.) is described in section 10.2.2.3, which 
should be read as background to this description. Overlay 
Services and Roll logic, and Overlay Programming Rules are 
described in sections 5.16, 4.20, and 12.14 respectively. 


6.3.2 HASP OVERLAY BUILD - PROGRAM LOGIC 


On initial entry, the time is sampled. A truncated "time- 
like" value is saved. This value will be placed into one 
resident CSECT and one overlay CSECT. During HASP Initiali- 
zation, if these two values do not match, an error message 
is produced and HASP terminates. 


All data sets are OPENed and the listing title line is printed. 
If the control card data set is present (ddname SYSIN), cards 
are read, printed, and processed until end-of-file is encoun- 
tered. Each card contains an overlayable CSECT name beginning 
in column 1, which must begin with "HAS". A SYM table entry 
is made for each such name. An Ocon (index into the Overlay 
Table, HASPOTAB) is asSigned and a priority, if present in 
column 16 of the card, is remembered. This information is 
later used to override the normal processing of that CSECT, 
when encountered in the object decks. A listing header line 
is printed at the end of control card processing. 


All objects decks are processed as a single sequential input 
data set (ddname SYSOBJ). Only the four object card types 
ESD, TXT, RLD, and END; as documented in OS/360 Loader PLM, 
Y28-6714, Figures 30-34; are processed. All other cards are 
written directly to SYSLIN. If an object card with a valid 
ESID number greater than the program's table limits (internal 
assembly variable &MAXESID) is encountered, the program abends 
with a U0101 code. 
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ESD card processing is essentially the construction of two 
Tables from ESD information. The SYM table contains the 
names of and information about any external names under over- 
lay control (i.e. beginning with "HAS"). It is a global | 
table covering all object decks together. A name is entered 
when a reference to it or CSECT definition of it is first 
encountered, or during control card processing as previously 
described. An overlay name in an ESD card item is first 
searched for in the SYM table, and if found, changes are 
made to the existing entry. An error message is produced 
for each duplicate definition of a previously defined over- 
lay CSECT name and only the first definition is used. An 
Ocon is assigned to each entry. When a name becomes a de- 
fined CSECT, if the fourth character is "O", the overlay 
routine is actually to be made disk resident, and storage 

is assigned to load its text. 


The ESID table is cleared at the beginning of each object 
deck and constructed as ESD items are encountered, under 
control of SYM table contents. It is a table of words, in 
order by ESID number. TXT and RLD card processing access 
this table only. It contains relocation values, Ocons, and 
flags controlling the disposition of text and RLD items. 


ESD items, for references to overlays or for definitions of 
overlay CSECTs which are to be disk resident or are dupli- 
cated, are eliminated from an ESD card when processed, before 
the ESD card is written to SYSLIN. This elimination is done 
by changing them to type NULL or, if type LD, by physically 
removing them and compacting the card. 


TXT card processing has three possible results. Text be- 
longing to an actual overlay is loaded into memory, subject 
to relocation according to storage assigned by ESD proces- 
Sing. Text of any overlay CSECT which is a duplicate of one 
encountered previously is discarded. Text of non-overlay 
CSECTs or overlays being made permanently resident is written 
un-altered to SYSLIN. 


RLD card processing concerns individual RLD items, as follows. 
If an item applies to a discarded duplicate overlay CSECT, it 
is eliminated. If an item references a non-overlay CSECT, 

it is left un-altered. An overlay reference item describes 

a 2 byte Q type constant assembled in the expansion of the 
SLINK, SLOAD, $XCTL, and S$OCON macros. The reference is 
resolved by substituting the Ocon value assigned to the ref- 
erenced overlay routine, and the item is eliminated. If the 

Q constant exists in an actual overlay routine, the Ocon value 
is simply moved to the proper address of the text already load- 
ed in memory. If the Q constant exists in a non-overlay CSECT 
or overlay being made resident, a new TXT card containing the 
Ocon value is created and written to SYSLIN. Eliminated items 
are physically removed and the RLD card compacted before 
writing to SYSLIN. | 
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END card processing is really end-of-object-deck processing. 
The card is written unchanged to SYSLIN. The entire SYM 
table is then scanned for selected processing. Each actual 
overlay whose text was loaded from the most recent object 
deck is written to OLAYLIB as a fixed length record of length 
&OLAYSIZ (internal assembly variable set to 1024 bytes in 
unmodified HASP). A listing line is printed for each overlay 
CSECT defined in the most recent deck, with its assigned Ocon 
value. Priority and disk address in two forms are printed for 
actual overlays. An error message is printed if an actual 
overlay length exceeds &OLAYSIZ. 


Processing of multiple object decks continues as above until 
end-of-file for SYSOBJ is signalled. The entire SYM table 
is then processed to produce the Overlay Table, which is 
written to SYSLIN as a new object deck (did not exist in the 
input) containing a single resident CSECT, HASPOTAB. An 
error message is printed for any name in the SYM table which 
1s still not defined as a CSECT. 


Each entry in HASPOTAB is 4 bytes or, if &DEBUG is set to 
YES, 12 bytes. The last 4 characters of the CSECT name are 
included if entries are 12 bytes, to facilitate identifica- 
tion in a memory dump. If a routine is actual overlay (disk 
resident), the TR (relative form) of disk address and the 
priority are placed into the table entry for that routine. 

If an overlay routine was written to SYSLIN by previous pro- 
cessing (to become permanently resident in the HASP load 
module), a V type constant is created in its table entry. 

An appropriate RLD item referencing the CSECT name is created. 


When HASPOTAB is complete, an END card for it is written to 
SYSLIN, all data sets are CLOSEd and the program terminates. 
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6.4 HASP REP ROUTINE 


This routine gives the systems programmer the capability of 
applying absolute or relocatable value patches to HASP, at 
absolute or relocatable memory addresses, as part of the HASP 
Initialization process. 


6.4.1 REP Card Format 


Columns Contents 
Any identification - ignored by REP routine 
2-5 CSECT name, "REP", or "ABS" 
6 Blank 
7-12 Address at which to apply patch (6 hex digits) 
or blank | 
13-16 Blank 


17-blank Half word absolute value patches, 4 hex digits 
each, separated by commas, patch data 
terminated by first blank, 
or one full word (8 hex digit; relocatable 
value patch, followed by a comma and the 
name of the resident CSECT which defines the 
relocatable part of the value 


The above format allows patches to be applied at any absolute 
memory location (by use of REP or ABS beginning in column 2) or 
at addresses in HASP CSECTs (resident or overlay), subject to 
relocation. Relocatable addresses should be taken directly from 
a HASP assembly listing containing the CSECT to be patched. A 
blank address field is interpretted as one greater than the last 
address patched by the previous card, but the card will be used 
only if columns 2-5 match those of the previous card. 


The patches may be absolute values or one relocatable word per 
card, whose value is relative to any resident HASP CSECT. 
Relocatable values should be punched as if they were the assembled 
value of an A type constant in the CSECT which defines the 
referenced relocatable symbol. 


Use of the term "CSECT name" in the above description means the 
fifth and following characters of a HASP CSECT name, as taken from 
the External Symbol Dictionary of a HASP assembly listing. 


A deck of one or more REP cards should be terminated by a card 
having "/*" punched in conune 1-2. 
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6.4.2 REP Routine - Program Logic 


REP cards, as described in Section 6.4.1, are read from the card 
reader, whose address is given by the HASPGEN parameter SREPRDR, 
immediately after the operator replys to HASP's initial WTOR, if 
the operator specifies "REP" in the reply options. Each card is 
listed on the printer, whose address is given by the HASPGEN 
parameter SREPWTR, unless the operator specifies "NOLIST" in the 
reply options. All I/O is performed using CPU instructions SIO 
and TIO with the CPU disabled for all interruptions. Cards are 
read and processed until a card having "/*" in columns 1 and 2 
is encountered or until the card reader signals unit exception. 


The value or data portion of each card is processed first. If 

the value is relocatable (indicated by comma in column 25), eight 
hex digits beginning in column 17 are converted to a binary value. 
The CSECT name (last four characters beginning in column 26) is 
located in an internal table of standard resident module names. 

A value is taken from this table which is the memory address at 
which the resident module is loaded. This value is added to the 
value taken from the card. 


If the value portion is absolute, groups of four hex digits (sep- 
arated by commas) beginning in column 17 are converted to binary 
values until a blank is encountered instead of an expected comma. 
The values are concatenated to form a single variable length 
binary value. 


The address portion of the card is processed next. If non-blank, 
Six hex digits beginning in-:column 7 are converted to a binary 
address. An attempt is made to locate the to-be-patched CSECT 
name (last four characters beginning in column 2) in the standard 
resident module name table. If located, the loaded memory address 
of the resident module is added to the address taken from the card. 
If the CSECT name is not in the standard resident module name 
table, the overlay table is searched to determine if the CSECT is 
an overlay which was made permanently resident. If so, the non- 
zero assembly origin of the wverlay CSECT is subtracted from and 
the loaded memory address is added to the address taken from the 
card. In both of the above cases, the patch value as previously 
computed is applied by moving it to the memory address determined 
by one of the two methods described. 


If the CSECT name is not located by either search just described, 
it is assumed to be an overlay CSECT which is not permanently resi- 
dent. The name, unrelocated address, and value are saved ina 
reserved area, to be applied each time the overlay is read from 
direct access during HASP operation. 


If the address field of the card is blank, the to-be-patched CSECT 
name is compared with that from the preceeding card. If they are 
not equal, the card is ignored. Otherwise, the card is considered 
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to be a continuation of the preceeding card and the patch value 
is applied at the next higher memory address or saved as appro- 
priate. 


If no area was reserved to save patch information for application 
to non-resident overlays (HASPGEN parameter &OREPSIZ=0) or if the 
Capacity of the reserved space is exceeded, the operator message 
"OVERLAY REPPING ERROR" is issued and HASP operation is abortively 
terminated. | | 
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6.5 HASP ACCOUNTING ROUTINE 


6.5.1 HASP Accounting Routine -~ General Description 


The Accounting Routine accumulates statistics for each job at the 
completion of the Punch phase and produces the HASP Account Card 
(see Section 11) which is punched by the Punch Processor. This 
feature is optional and may be deleted at HASPGEN time. 


6454.2 HASP Accounting Routine - Program Logic 


The HASP Accounting Routine is a separately assembled overlay seg- 
ment which gains control at the end of the Punch phase. Its func- 
tion is to construct an accounting card such that the Punch 
Processer can punch this card upon return. 

Upon entry, the following registers contain the following information: 
Register 1 - Address of the HASP Job Queue Entry Priority Byte. 
Register 2 - Address of the Accounting Card Image Area. 
Register 10 - Address of the HASP Job Control Table. 

Register 14 - Return Address. 

All registers must be saved and restored before return to HASP. 

This routine blanks out the Accounting Card Image Area and then 

extracts information from the HASP Job Control Table and HASP Job 

Queue Entry and constructs the Accounting Card Image in the Account- 

ing Card Image Area. Special consideration is made for the clock 

passing midnight. In such cases the elapsed time is negative and 

a correction factor (24 hours) must be added. | 

The accounting card which is normally punched when this routine 


returns to the punch processor may be deleted by setting the 
condition code to zero before returning. 
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6.6 HASP DUMP ROUTINES 


HASP provides two dump routines which are optionally included 

as debugging aids. The HASP Dump Routine for printer formatted 
dumps and the HASP High Speed Dump to Tape Routine are discussed 
in the following sections. 


6.6.1 HASP Dump Routine - General Description 


The $Dump routine is available as a debugging aid (effective only 
if &DEBUG=YES and will, when the console PSW RESTART key is de- 


pressed, dump memory according to specified limits. 


6.6.2 HASP Dump Routine - Program Logic 


This routine gains control via the PSW RESTART key on the console. 
Upon activation of the key, a specially formatted HASP PSW is loaded 
from location HEX'0O'. The format is HEX'O004000F for the first 
word; where 0004 is the mask that allows only a machine check 
interrupt, and OOOE is the address of the printer that is referenced 
in the routine. The second word will contain the address of the 
-$Dump routine of HASP. 


Once activated, SDump will reference the low core address of HEX'30' 
for its beginning limit and HEX'34' for its ending limit. These 
limits default to values that will dump all of the memory unless 
the operator changes the limits prior to pushing the PSW RESTART 
key. If a change is desired, the limits should be entered at 
their respective locations in the following format: HEX'OOXXXXXX'. 
Also, if an operator should care to change the limits while SDump 
is activated, the routine will immediately note a change, will 
immediately stop the previous dump, and will start dumping memory 
within the new limits. It should be noted at this point that a 
machine check will destroy the limit values within their position 
in core. To avoid undetected machine checks, however, the dump 
program is, at all times, enabled for machine check interrupts. 


The routine also allows the operator to route the printing toa 
printer with an address other than HEX'OOE'. A change of the 
printer address in the HASP preformatted PSW, prior to activation 
of $Dump, will accomplish this. 


At the normal end of the routine, the system will be placed in a 
"wait" state via the LPSW command. At this point in time, the 
registers will have been restored back to their values prior to 
SDump and the default limits of $Dump will have been returned to 
their respective values. 
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HASP HIGH SPEED DUMP TO TAPE ROUTINE - GENERAL DESCRIPTION 


The High Speed Dump to Tape Routine, available as an optional 
debugging aid, dumps all of main storage to tape for post 
processing by the IBM System/360 Operating System Service 
Aids program IMDPRDMP or an equivalent processor. 


HASP HIGH SPEED DUMP TO TAPE ROUTINE - PROGRAM LOGIC 


ENTRY TO IDMTAPE - If the system programmer sets the HASPGEN 
parameter &DMPTAPE to the address of an attached magnetic tape 
drive the High Speed Dump to Tape Routine (IDMTAPE) will be 
created to write on the specified drive when entered. Initial- 
ization will display on the operator's console the message 
"SET RESTART PSW TO 0004000000aaaaaa FOR TAPE DUMP" where 
"aaaaaa" is the address of the entry point IDMTAPE. This 
message not only verifies that the routine is present; it is 
sufficient information for the operator to manually activate 
the dump. Via the REP processing routine or via manual key 
entries the system programmer or operator is able to insert 
code within the system to detect errors and cause dumps by 
program entry to the routine simulating the loading of the 
requested PSW. (Example: set program new PSW as directed to 
dump on the first program check.) 


IDMTAPE assumes that the device generated is an appropriate 
tape drive to use, that the tape is at load point ready for 
writing, and that the recording mode status is correctly set. 
If these conditions are not true unpredictable results will 
occur. 


CHANGING THE TAPE ADDRESS - The halfword located in storage 

at IDMTAPE-4 contains the address of the tape drive upon which 
the routine will write when entered. This address may be 
altered manually to any other tape drive address as appropriate 
prior to executing the routine. 


PROGRAM LOGIC - The general registers and selected fixed 
storage areas are saved in location 84 hexadecimal to be 
compatible with the OS Service Aids dump program. 


HASP control section locator elements are moved into low 
storage adjacent to the fixed area information. These elements 
contain the last four characters of the "HASPxxxx" control 
section names of basic assembly modules. Following each CSECT 
identification is the address of the beginning of the identi- 
fied CSECT. (HASP control sections may then be easily located 
in the dump after post processing.) Location 80 hexadecimal 
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is set to the negative 
for 4 bytes is written 
part of which contains 


Each succeeding record 


of address 2048. Location 80 hexadecimal 
followed by 2048 bytes of storage (first 
saved data). 


7 


is written by adding the address 2048 


to the address in location 80 (hex), storing the memory protect 
key in the high byte, and writing 2052 bytes of storage (four 


from location 80 (hex) 


and 2048 from the designated address). 


When the address is greater than zero the program new PSW is 
set to provide an end of storage exit which, when entered, _ 
will cause the writing of EOF, a rewind unload, and the loading 


of a wait state PSW. 


HAS P 
7.0 HASPGEN AND RMTGEN PARAMETERS 


This section describes the parameters used to specify 
the HASP System, HASP MULTI-LEAVING Remote Terminal 
Programs, and the System/360 Model 20 STR Remote 
Terminal Program. 


Generation of the HASP System is called HASPGEN, .and 
generation of the HASP MULTI-LEAVING Remote Terminal 
Programs and the System/360 Model 20 STR Program 

for HASP Remote Job Entry is called RMTGEN. Both 
generation processes are described in Section 10. 
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7T.l HASPGEN PARAMETERS 


Generation of a HASP System involves specification 
of certain parameters, called HASPGEN parameters. 
With these parameters, the installation system 
programmer specifies the characteristics of the 

System/360 or System/370 with which he will use 
HASP and the optional HASP features he wishes to be 
included in the generated HASP System. 


The following pages describe the HASPGEN parameters. 
For each parameter there is an explanation, the de- 
fault value, and frequently notes which expand upon 
the explanation and refer to related HASPGEN 
parameters. 


The HASPGEN parameters are given in alphabetical order 


(neglecting the first character if it is & or $) 
except for parameter $$x, which appears last. 
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& ACCTNG 


&ACCTNG 


Explanation: Variable symbol &ACCTNG. specifies the 
HASP job accounting option. If it is specified as 
YES, HASP will call the HASP accounting routine and 
punch a HASP accounting card for each job processed 
by HASP. The specification must be either YES or NO. 


Default: &s&ACCTNG=YES 


Notes: 
1. The HASP accounting routine and the HASP ac- 


counting card are discussed in other sections 
of this manual. 


2 If &NUMPUNS=0, Saraneeed &ACCTNG should be 
set to NO. 
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&AUTORDR 


&AUTORDR 


Explanation: Variable symbol &AUTORDR specifies 

the inclusion or exclusion of code in HASP to recog- 
nize automatically when a physical card reader 
available to HASP becomes ready. The specification 
must be either YES or NO. 


Default: &AUTORDR=YES 


Notes: 

io If &SAUTORDR=NO, HASP's physical card readers 
remain in the INACTIVE state when they become 
ready; the operator must issue a $SRDRn command 
to cause HASP to begin reading cards from 
READERN. 
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&BSCCPU 


Explanation: Variable symbol &BSCCPU specifies inclusion 
or exclusion in the HASP Remote Terminal Access Method 
of support for HASP MULTI-LEAVING Remote Job Entry. 


Default: &BSCCPU=NO 
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&BSC2770 


Explanation: Variable symbol &BSC2770 specifies inclu- 
sion or exclusion in the HASP Remote Terminal Access 
Method of Remote Job Entry support for the 2770 Data 
Communication System. The specification must be either 
YES or NO. 


Default: &BSC2770=NO 
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&BSC2780 


&BSU2/80 


Explanation: Variable symbol &BSC2780 specifies inclu- 
sion or exclusion in the HASP Remote Terminal Access 
Method of Remote Job Entry support for the 2780 Data 
Transmission Terminal. The specification must be 
either YES or NO. 


Default: &BSC2780=NO 
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& BSHPRSU 


&BSHPRSU 


Explanation: Variable symbol &BSHPRSU specifies inclu- 
Sion or exclusion of the HASP Remote Job Entry Printer 
Interrupt feature for binary synchronous hardware 
terminals. If this feature is included, the Remote 
Terminal operator may interrupt printing to transmit 
jobs or HASP commands to HASP. The specification 

must be either YES or NO. 


Default: &BSHPRSU=YES 


Notes: 

1 If &BSHPRSU=YES, HASP will recognize certain 
control characters from the binary synchronous 
hardware terminal which indicate that the printer 
has stopped. The HASP Remote Terminal Operator's 
Manual for hardware terminals contains more infor- 


mation. 
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& BSVBOPT 


Explanation: Variable symbol &BSVBOPT specifies inclu- 
sion or exclusion in the HASP Remote Terminal Access 
Method of code to recognize an EM (End of Media) punch 
in card images transmitted nontransparently by the 

2780 Data Transmission Terminal. The specification 
must be either YES or NO. 


Default: &BSVBOPT=NO 
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& BUFHICH 


&BUFHICH 


Explanation: Variable symbol &BUFHICH specifies the 
storage hierarchy for which HASP initialization will 
issue a GETMAIN in an attempt to get more than &NUMBUF 
buffers for HASP. The specification must be either 

0 or l. 7 | 7 


Default: &BUFHICH=1 


Notes: 


i &BUFHICH has meaning only with OS storage hier- 
archy support. 

2% See HASPGEN parameters &NUMBUF, &MINBUF and 
&RESCORE for additional information concerning 
the use of this parameter. 
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&BUFSIZE 


&BUFSIZE 


Explanation: Variable symbol &BUFSIZE specifies 
the size in bytes of each HASP buffer. If the 
value specified is not a multiple of eight, 
HASPGEN will adjust it upward to a multiple of 
eight. The specification must be an integer not 
larger than the track size of any SPOOL device 
and not smaller than the number given by 
300+2* sNUMDA* &NUMTGV/8+5*S+8*F 
where S = maximum allowable number of SYSOUT 
specifications per job, including 
special forms requests 
F = maximum allowable number of special 
forms requests per job. 


Default: &BUFSIZE=688 


Notes: 

L: The above formula is the approximate size 
of a HASP control block called the JCT. 
&BUFSIZE is the data length of each physical 
record on the portion of a SPOOL volume used 
by HASP, and JCTs are written on SPOOL volumes. 
A JCT's initial size is about 
300 + 2*&NUMDA* &NUMTGV/8; it increases in size 
as a job is being executed. When HASP recog- 
nizes a job step change, the JCT is increased 
in size by five bytes for each non-special- 
forms SYSOUT data set, or by thirteen bytes 
for each special-forms SYSOUT data set, that 
was written upon since the previously-recog- 
nized step change. But if an increase of five 
(or thirteen) bytes would cause the JCT size 
to become greater than &BUFSIZE, HASP instead 
writes to operator the message 

JCT OVERFLOW~-OUTPUT LOST 7 

for the SYSCUT data set, and its output is lost. 

2% The default &BUFSIZE of 688 is optimized for 
the 2314 track size. If &NUMTGV and &NUMDA 
are left at their default values of 400 and 2, 
the &BUFSIZE default allows a maximum of 37 
(no special forms) and a minimum of 14 (all 
special forms) SYSOUT data sets per job. A 
good value of &BUFSIZE optimized for the 3330 
would be 736. 
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SCKPTIME 


$CKPTIME 


Explanation: Ordinary symbol SCKPTIME specifies the 
interval, in seconds, at which certain HASP informa- 
tion will be checkpointed for warm start purposes. 


Default: SCKPTIME=60 


Notes: 

Ls The time interval specified is a maximum. Check- 
points are also taken when a job changes its 
status in the HASP job queue. 


Ji The section of this manual describing the HASP 
checkpoint processor describes the checkpoint 
information. 
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- &CLS (n) 


Explanation: Subscripted variable symbols &CLS(n) 
specify HASP job classes. The nth HASP logical 
partition may Select for OS execution a job from 

the HASP job queue only if the job's class (specified 
by the user in the CLASS=parameter of the JOB card, 
or defaulted to A) is one of the characters specified 
in the &CLS(n) parameter or specified by the operator 
in the set command, ST Imm,list (where &PID(n)=mm). 
Each specification must be a 1- to 8-character string 
of valid HASP job classes. The same HASP job class 
may be specified in two or more specifications. 


Default: 6&CLS(1)=A 
&CLS (2) =BA 
&CLS (3) =CBA 
&CLS (4) =DCBA 
&CLS (5) =EDCBA 
&CLS (6) =FEDCBA 
&CLS (7) =GFEDCBA 
&CLS (8) =HGFEDCBA 
&CLS (9) =IHGFEDCB 
&CLS (10) =JIHGFEDC 
&CLS (11)=KJIHGFED 
&CLS (12) =LKJIHGFE 
&CLS (13) =MLKJIHGF 
&CLS (14) =NMLKJIHG 
&CLS (15) =ONMLKJIH 


Notes: 

13 Only the first &MAXPART specifications, &CLS (1) 
through &CLS(&MAXPART), will be used. 

2% If &MAXCLAS is specified less than 8, only the 


first &MAXCLAS characters of each specification 
&CLS(n) will be used. 
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& CONAUTH 


-&CONAUTH 


Explanation: Variable symbol &CONAUTH specifies the 
HASP command authorization of each of the eight possible 
HASP physical consoles when HASP console support is 
included in the generated HASP system. The specifi- 
cation must be a string of up to eight numeric digits, 
each of which may range from 0 to 7 and is the sum 

of the desired authorizations for its respective 

console (leftmost digit for CONSOLE 1, next digit 

for CONSOLE2, etc.) as follows: 


1 - System Control (including OS) Commands 
2 - Device Control Commands 
4 - Job Control Commands. 


Default: &CONAUTH=77777777 


Notes: | 

Le Any HASP console's command authorizetion may be 

changed from a console with System Control 

Command authority. 

‘ If &NUMCONS=0, parameter &CONAUTH is not used. 

36 All HASP consoles are authorized for the issuance 
of Display Commands. : 
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& DEBUG 


&DEBUG 


Explanation: Variable symbol &DEBUG specifies inclu- 
Sion or exclusion of debugging code in the generated 
HASP system. The specification must be either YES 

or NO. 


Default: &DEBUG=NO 


Notes: 

Ls The &DEBUG option is independent of the &TRACE 
option. | : 

2% If &DEBUG is specified as YES, HASP includes, 
in addition to other debugging code, a core dump 
rouine. 
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SDELAYCT 


$DELAYCT 


Explanation: Ordinary symbol S$DELAYCT specifies a 
delay factor to be applied by the HASP Remote Terminal 
Access Method when transmitting to a Multi-Leaving 
System/360 Model 20 Sub-Model 2 Remote Terminal over 

a high-speed (19,200 baud or greater) teleprocessing 
line, to avoid the possibility of certain line errors. 
The specification must be an integer greater than 
zero. Recommended values for some central CPUS are: 


Model 
Model 
Model 
Model 
Model 
Model 


4000 
3000 
500 
256 
100 
1 


Values for other CPUs may be interpolated based on 


CPU speed. 


Default: SDELAYCT=256 
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& DMPTAPE 


&DMPTAPE 


Explanation: Variable symbol &DMPTAPE specifies a 
unit address to be used with the HASP dump program. 
The specification must be a valid unit address. If 
the specification is not 000, the address is assumed 
to be that of a tape drive and the generated HASP 
system will include a dump-to-tape program for that 
tape drive. The tape produced by this program may 
be printed using FE Service Aid IMDPRDMP. 


Default: &DMPTAPE=000 


Notes: 

Ls This parameter does not affect inclusion of the 
HASP dump-to-printer program, which is always 
assembled if &DEBUG=YES. To use the dump-to-tape 
program the operator must set location 0 as in- 
dicated in an operator message produced by HASP 
initialization, make the tape drive ready for 
writing, and push PSW RESTART. 

Dive This facility is provided as an aid to the 
system programmer and may not operate correctly 
in all environments or with other than the 
IMDPRDMP program provided with Release 19 of 
OS. No maintenance will be provided for this 
facility. Installations unable to utilize this 
Support as distributed should utilize the service 
aid IMDSADMP to produce dump tapes. 
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SESTIME 


$SESTIME 


Explanation: Ordinary symbol SESTIME specifies 


the default estimated execution time, 


in minutes, 


for a job. The specification must be an integer 


greater than zero. 
Default: SESTIME=2 


Notes: 

1. If a user does not specify in the 
field of his job card a value for 
execution time, the value SESTIME 

2. All timings performed by HASP are 


accounting 
estimated 
is used. 
in real 


time. The timing for estimated execution 
time begins when HASP allows its OS Reader/ 
Interpreter to start reading the job. 
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SESTLNCT 


$SESTLNCT 


Explanation: Ordinary symbol $SESTLNCT specifies 
the default estimated print line count, in thou- 
sands of lines, for a job. The specification must 
be an integer greater than zero. 


Default: SESTLNCT=2 
Notes: | 
se If a user does not specify in the accounting 


field of his job card a value for estimated 
print line count, the value SESTLNCT is used. 
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SESTPUN 


SESTPUN 


Explanation: Ordinary. symbol $ESTPUN specifies 

the default estimated punched card count, in cards, 
for a job. The specification must be an integer 
greater than zero. 


Default: SESTPUN=100 
Notes: | 
I. If a user does not specify in the accounting 


field of his job card a value for estimated 
card count, the value SESTPUN is used. 
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& INITSVC 


&INITSVC 


Explanation: Variable symbol &SINITSVC specifies the 
SVC number of the HASP SVC. The specification must 
be an integer between 200 and 255, inclusive. 


' Default: &INITSVC=255 


Notes: 

ls The specification for &INITSVC must correspond 
to a use at SYSGEN time of the OS SYSGEN macro- 
instruction SVCTABLE. The HASP SVC is a type-l 
SVC and must be included in the OS Nucleus before 
HASP can be used. After HASPGEN has completed, 
the object deck for the HASP SVC is member 
HASPSVC of partitioned data set SYS1.HASPOBJ. 
For further discussion, see the section on in- 
stalling HASP. 
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&JITSIZE 


&JITSIZE 


Explanation: Variable symbol &JITSIZE specifies 


the number of bytes per entry of the HASP job infor- 
mation table. The specification must be an integer 
greater than or equal to 8, or equal to 0, but never 
so large that the value 

&MAXJOBS* &JITSIZE 
is greater than the track size of the sevice upon 
which SPOOL] is mounted. , 


If &JITSIZE=0, the HASP command $D'jobname' will be 


lnoperative. 


Default: &JITSIZE=0 


Notes: 

Ls The recommended specifications for &JITSIZE are 
0 and 8. If &JITSIZE is set greater than 8, 
the additional space generated in the job infor- 
mation table will not be used by HASP. 

2% If &JITSIZE is specified greater than zero, the 
job information table will be checkpointed on 
SPOOL] whenever it changes. 
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SLINECT 


SLINECT 


1 


Explanation: Ordinary symbol $LINECT specifies the 
default maximum number of lines to be printed per 
page of a job's printed output. 


Default: SLINECT=61 


Notes: 

Le If a user does not specify in the accounting 
field of his job card a value for line count, 
the value S$LINECT is used. | 
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LINEmm 


Code Letters 


mm 


aaa 


Explanation: 


LINEmm 


Ordinary symbols LINEmm specify the 


characteristics of teleprocessing lines to be used 


by HASP Remote Job 


LINEmm=aaalc 


Entry. 


Lines must be defined con- 
secutively, starting with LINEOIL. 


Each specification 
must be a 5-character string of the form 


where the letters represent the following: 


Duplex 
Duplex 


Duplex 
Duple 


(1200-9600 
(1200-9600 
(19.2-230.4 
(1200-9600 
(1200-9600 


(19.2-230.4 


Range Description 
01-99 Line Number 
000-FFF STR or BSC Adapter Address (See Note 2): 
0-5 Line Description as follows: 
STR Lines 
0 = Interface A 2 wire Half- 
l = Interface A 4 wire dalf- 
2 = Interface A Full-Duplex 
3 = Interface B 2 wire Half- 
4 = Interface B 4 wire Half- 
5 = Interface B Full-Duplex 
0-5 BSC Lines 
O = Interface A Half-Duplex 
baud) 
1 = Interface A Full-Duplex 
baud) 
2 = Interface A Full Duplex 
k-baud) 
3 = Interface B Half-Duplex 
baud) 
4 = Interface B Full-Duplex 
baud) 
5 = Interface B Full-Duplex 
k-baud) 
Clock/Code as follows: 
0-3 STR Lines 
0 = Internal Clock X 
1 = Internal Clock Y 
2 = Internal Clock 2@ 
3 = External Clock 


HAS P 


Code Letters 


Range Description 
0-7 BSC Lines 

O = Code A —- EBCDIC - No Transparency 
1 = Code A - EBCDIC - Transparency 

2 = Code A - USASCII - No Transparency 
3 = Code A - USASCII - Transparency 

4 = Code B ~—- EBCDIC - No Transparency 
5 = Code B - EBCDIC - Transparency 

6 = Code B - USASCTI - No Transparency 
7 = Code B - USASCITI - Transparency 


Default: LINEmm=***01] 


Notes: 


Is 


2. 


Parameter &NUMLNES must specify the number of 
specifications LINEmm to be included in the gene- 
rated HASP system. 

The unit address aaa may be specified AS). ees 

HASP initialization will assign unit addresses 

to lines whose unit addresses are specified as 
*** by scanning the OS UCBs. A teleprocessing 
UCB whose device type field specifies a 2701 

STR adapter, a 2701 BSC adapter, or a 2703 BSC 
adapter will be recognized as a UCB defining a 
line. If the unit address of such a UCB is not 
specified explicitly in any of the first &NUMLNES 
line definitions LINEmm, HASP initialization 

will assign the UCB to the first line number 
whose unit address is specified *** and will 
change the *** to the EBCDIC address specified 

in the UCB, unless no line definition remains whose 
unit address is ***, or if (except for M65MP and 
a 2-CPU multiprocessor) a TIO shows the line not 
operational, or if (for M65MP and a 2~-CPU multi- 
processor) the UCB is marked off-line; in that 
case HASP will not use the line. 

If a line specification LINEmm designates USASCII, 
that line cannot be used with any but 2770 and 
2780 USASCII terminals. HASP will translate each 
record it receives into EBCDIC, and each record 
it transmits into USASCII before transmission. 
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&LOGOPT 


Explanation: Variable symbol &LOGOPT specifies 
inclusion or exclusion of code to support the HASP 
System Log feature. The specification should be 
either YES or NO. 


Default: &LOGOPT=YES 


Notes: 
ds The HASP System Log is a listing included in 
each user's output of console messages that 
were produced during processing of the job and 
(unless &NUMCONS=0) of replies to WTORs issued 
during processing of the job. 
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&MAXCLAS 


&MAXCLAS 


Explanation: Variable symbol &MAXCLAS specifies 
the maximum number of job classes which may be 
specified via the HASP command $T In,list for a 
HASP logical partition. The specification must 
be an integer from 1 to 64, inclusive. 


Default: &MAXCLAS=8 


Notes; 

Le If &MAXCLAS is specified as less than 8, then 
no more than &MAXCLAS characters may be speci- 
fied for each of the parameters &CLS(n). 
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&MAXJOBS 


Explanation: Variable symbol &MAXJOBS specifies the 
maximum number of jobs that can be in the HASP System 
at any given time. The specification must be an 
integer greater than zero. 


Default: &MAXJOBS=100 


Notes: 

deg This variable does not affect the range of 
HASP job numbers, which is 1 to 999. 

2 This variable strongly influences the size of 


the HASP checkpoint record(s). The size of 
the first checkpoint record is 
16* (&MAXJOBS+&NUMPRTS+&NUMTPPR) + 
&NUMDA* ( (&NUMTGV+7) /8) +40. 
The size of the second checkpoint record is 
&MAXJOBS* &JITSIZE. 
If either checkpoint is longer than the track 
size of the device on which SPOOL! is mounted, 
HASP will not warm start correctly. 
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&MAXPART 


&MAXPART 


Explanation: Variable symbol &MAXPART specifies, 
for both MFT and MVT, the number of HASP logical 

partitions to be defined. The specification must 
be an integer between 1 and 15, inclusive. 


Default: &MAXPART=&MAXXEQS 


Notes: 

Ts The nth logical partition is further defined 
by the specifications &PRI(n), &OSC(n), and 
&CLS (n). 


HASPGEN Parameters - Page 7.1.28 


337 


HAS P 


&MAXXEQS 


~ &MAXXEQS 


Explanation: Variable symbol &MAXXEQS specifies 
the maximum number of jobs which may concurrently 
be active in the HASP Execution phase. The speci- 
fication must be an integer greater than zero. 


Default: é&MAXXEQS=3 
Notes: 


Ls See also &MAXPART, the variable which deter- 
mines the number of HASP logical partitions. 
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&MIN BUF 


&MINBUF 


Explanation: This variable is provided to allow instal- 
lations, which depend on the dynamic buffer construction 
feature of HASP, to detect the condition where sufficient 
buffers for proper operation cannot be obtained. The 
specification should be an integer value representing 

the minimum number of buffers determined as necessary 

for the installation (see &NUMBUF). 


Default: &MINBUF= 3*&MAXXEQS+2*&NUMRDRS 
+&NUMINRS+2* &NUMPRTS+ &NUMPUNS 
+&NUMTPBF 


Notes: 

Ls HASP will automatically attempt to utilize, via a 
variable GETMAIN, any free space in its region or 
partition (hierarchy indicated by &BUFHICH) as 
additional buffers. If the number of buffers so 
obtained when added to the variable &NUMBUF is less 
than the value of &MINBUF the warning message 

&MINBUF BUFFERS NOT AVAILABLE 
will be issued during HASP initialization and pro- 
cessing will continue. 

2% Since the changing of HASPGEN options, local 
modifications and/or OS changes can affect the 
number of HASP buffers, proper setting of this 
variable can prevent a possible undetected perfor- 
mance degradation. 

3% See the description of HASPGEN parameters &NUMBUF, 
&BUFHICH and &RESCORE for related information. 
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&MLBFSIZ 


&MLBFSIZ 


Explanation: Variable symbol &MLBFSIZ specifies 

the size in bytes of each HASP Multi-Leaving buffer. 
The specification for &MLBFSIZ must be a positive 
integer no larger than &TPBFSIZ. 


Default: &MLBFSIZ=&s&TPBFSIZ 


Notes: 

LS The value specified for &MLBFSIZ automatically 
becomes’ the Multi-Leaving buffer size in each 
HASP Multi-Leaving Remote Terminal program. 

Be The defaults given for &TPBFSIZ and &MLBFSIZ 
are judged to be practical minimum values and 
to give suitable performance for medium-speed 
teleprocessing lines. 
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&MONINTV 


Explanation: Variable symbol &MONINTV specifies the 
interval in seconds at which the HASP Execution Task 
Monitor will examine CPU utilization characteristics 
and, if necessary, modify dynamically the order in 
the TCB chain, of all HASP-controlled job step tasks 
which fit Execution Task Monitor criteria. The 
specification should be an integer between 0 and 10 
inclusive. If &MONINTV is specified as zero, the 
Execution Task Monitor is excluded from the generated 
HASP system. 


Default: é&MONINTV=5 


Notes: 
dix See also parameters &XZPRTY (for MVT), &XZMFTL, 
and &XZMFTH. 


HASPGEN Parameters - Page 7.1.32 


341 


&NOPRCCW 


&NOPRCCW 


Explanation: Variable symbol &NOPRCCW specifies the 
maximum number of channel command words per channel 


program for local printers. 


Default: s&NOPRCCW=15 
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&NOPUCCW 


Explanation: Variable symbol &NOPUCCW specifies the 
maximum number of channel command words per channel 
program for local punches. 


Default: &NOPUCCW=10 
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&NUMBUF 


&NUMBUF 


Explanation: This variable symbol indicates the number 
of INPUT/OUTPUT buffers to be included in the HASP 

load module and should normally be set by each instal- 
lation, according to the formulae below, to reflect the 
total number of buffers required for proper operation 

of HASP. However, since HASP will automatically utilize 
free space in its region or partition to dynamically 
construct additional buffers, there are circumstances 
when &NUMBUF may be set to a value less than the actual 
number of buffers required for proper HASP operation. 

In this case, it is assumed that sufficient additional 
buffers will be dynamically obtained from free storage 

in the HASP region/partition to provide an adequate 

total number of buffers (see &MINBUF and &RESCORE). 

This facility could be used, for example, to allow 
additional buffers to reside in a storage hierarchy 
different from that of the HASP load module (see &BUFHICH) 
or to provide a HASP whose size (and performance and 
function) can be controlled by the setting of the region 
or partition size. 


Default: &NUMBUF=1L5 


Notes: 

I In order to utilize all the dynamic storage con- 
tained in the HASP load module for the initialization 
process, the value of &NUMBUF must never be less 
than the value | 

1+6000/ (80+&BUFSIZE) 

2% Since all HASP buffers are maintained in a dynamic 
pool until required by an active function, instal- 
lation should determine the appropriate number of 
buffers for HASP based on predicted simultaneity 
of the various functions required at the installa- 
tion. The following indicates the number of buffers 
required for each logical function. A defined 

function which is inactive requires no buffers. 


Each local input function --2 

Each internal reader --1 

Each Remote Input function ~-l 

Each local print function --2 (1 if SPRTBOPT=1) 
Each remote print function --l (2 if $RPRBOPT=2) 
Each local punch function --l1 (2 if SPUNBOPT=2) 
Each remote punch function --l1 (2 if S$RPUBOPT=2) 
Each OS job execution. --2 (minimum value) 
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For performance reasons, additional buffers must 

be available to sustain periods of high SYSIN/ 
SYSOUT activity by jobs being processed by OS. 

It is therefore recommended that additional buffers 
(beyond the requirements indicated above) be inclu- 
ded corresponding to the value: 1+&MAXXEQS. 


SEVERE PERFORMANCE AND/OR DEVICE DEGRADATION CAN 
OCCUR IN A SYSTEM CONTAINING INSUFFICIENT BUFFERS 
TO PERFORM THE REQUIRED FUNCTIONS. 
To avoid a complete system failure caused by a 
buffer "lock-out" condition, the number of available 
buffers must never be less than the value 
&MAXXEQS+&NUMRDRS+&NUMTPES+1 

+&NUMPRTS* (S$PRTBOPT-1) 

+&NUMPUNS* (SPUNBOPT-1) 

+&NUMTPPR* (SRPRBOPT-1) 

+&NUMTPPU* (SRPUBOPT-1) 
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' &NUMCONS 


&NUMCONS 


Explanation: Variable symbol &NUMCONS specifies the 
type of console support to be provided by HASP. Two 
options are available: console support controlled 
totally by HASP or a HASP interface to the standard 


OS Console processors. 


The specification &NUMCONS=n (n an integer between 

one and eight) causes HASP to support directly as many 
as n consoles. The devices which may be used as con- 
soles are 1052, 1053, 3210, 3215, 2260 and 1443. The 
1053s and 2260's must be attached locally via a 2848. 


The specification &NUMCONS=0 causes HASP to interface 
with the OS console support, including the MCS option. 
All devices available with the OS console routines are 
Supported through this interface. 


Default: &NUMCONS=0 


Notes: 

I. If &NUMCONS=0 is specified, then all HASP functions 
with the exception of those listed below are pro- 
vided. 


a. Non-HASP Messages, e.g., problem program WTOs, 
will appear on the console(s) without time 
tags or HASP Job numbers. A copy of the mes- 
sage which includes the Job number and time 
tag is placed in the HASP System Log. 


b. WTORS issued by the problem program will be 
included in the HASP Log without the OS as- 
Signed reply identification number. 


c. Replies to outstanding WTORS are not included 
in the HASP log. 


2% If OS Multiple Console Support or M65MP or the 
Time Sharing Option have been SYSGENed and are to 
be used with HASP, then &NUMCONS should be speci- 
fied as zero. 


3. If &NUMCONS greater than zero is specified and if 
HASP initialization finds more than &NUMCONS de- 
vices of the type supported then the message 


MAXIMUM OF &NUMCONS CONSOLE(S) EXCEEDED 
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1S issued and HASP uses as consoles the devices 
with the lowest unit addresses starting with the 
first 1052, 3210 or 3215 and continuing with the 
next &NUMCONS-1 devices. 


4, 2260 support (&NUMCONS greater than zero) is 
dependent on additional specifications via the 
variables &SIZ2260 and &SPD2260. 


Di If &NUMCONS is specified greater than zero, HASP 
will intercept and process all WTOs and WTORs, 
ignoring all MCS information. In particular, 
HASP will ignore all routing codes. Thus, for 
example, a WTO with ROUTCDE=11 will be written 
on HASP consoles and on the HASP System Log but 
not in an OS System Message Block. 


6. See parameter &CONAUTH, &WTLOPT and &LOGOPT for 
additional information. 
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&NUMDA 


&NUMDA 


Explanation: Variable symbol &NUMDA specifies 
the maximum number of direct-access volumes which 


may be mounted concurrently as SPOOL volumes. The 
specification must be an integer greater than zero. 


Default: &NUMDA=2 


Notes: 

ds All direct-access devices except 2321s are 
eligible for use as SPOOL devices. 

as Specifying &NUMDA greater than the default may 
require increasing the value of &BUFSIZE. 

Se If HASP initialization finds mounted more than 


&NUMDA direct-access volumes whose volume 
serials begin with the characters SPOOL, it 
will write to operator the message 

MAXIMUM OF &NUMDA SPOOL VOLUME(S) EXCEEDED 
and HASP will quiesce. 


4. This variable influences the size of the HASP 
checkpoint record; see Note 2 of variable 
&MAXJOBS. 

5. An associated variable is &NUMTGV. 
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& NUMDDT 


&NUMDDT 


Explanation: Variable symbol &NUMDDT specifies the 
qanbes of Data Definition Tables (DDTs) to be assem- 
bled into HASP. The specification should be an 
integer between 3 and 256, and equal to 
2+ &MAXXEQS +A+B+C+D+E 
where 
A = number of pseudo-2540 readers defined at 
SYSGEN time : 
B = number of pseudo-2540 punches defined at 
SYSGEN time 
C = number of pseudo-1403 printers defined at 
SYSGEN time 
D = number of pseudo-1442 punches defined at 
SYSGEN time 
E = number of pseudo-1443 printers defined at 
SYSGEN time 


Default: &NUMDDT=20 


Notes: | 
1. Pseudo-units for &RDR and &WTR need not be 
counted in &NUMDDT. 
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&NUMINRS 


&NUMINRS 


Explanation: Variable symbol &NUMINRS specifies 
the number of 2520 pseudo-punches to be used by the 
generated HASP System as internal readers. 


Default: &NUMINRS=0 


Notes: 


Le. 


If &NUMINRS is specified as or defaulted to 
zero, code to support the HASP internal reader 
feature will be deleted from the generated 
system. 

If more than &NUMINRS 2520 pseudo-punches have 
been specified at SYSGEN time, only the first 
&NUMINRS 2520 pseudo-punches can be used. It 
1s permissible to specify &NUMINRS greater 
than the number of 2520 pseudo~-punches speci- 
fied at SYSGEN time. 

The count of 2520 pseudo-punches is not 
included in HASPGEN variable &NUMDDT. 
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&NUMLNES 


&NUMLNES 


Explanation: Variable symbol &NUMLNES specifies 

the largest teleprocessing line identification 
number (mm in LINEmm) and thus the number of line 
definitions which are to be used by the generated 
HASP System. The specification must be an integer 
between 0 and 99 inclusive. The specification for 
&NUMLNES automatically becomes the specification 

for &NUMRJE, unless &NUMRJE is specified explicitly. 


Default: &NUMLNES=0 





Notes: 
Ls See also the HASPGEN variable LINEmm. 
2 If &NUMLNES is set to or left at zero, all 


other Remote Job Entry parameters should 
be left at their default values. 
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& NUMOACE 


&NUMOACE 


Explanation: Variable symbol &NUMOACE specifies the 
number of overlay areas to be provided for the standard 
HASP Overlay feature. The specification must be an 
integer greater than zero. | | 


Default: &NUMOACE=1 


Notes: 

i It is judged that more than two overlay areas 
will benefit only a system with high performance 
orientation (a very fast CPU or a work load con- 
Sisting of a large number of short jobs). 

2% See also parameter &OLAYLEV. 
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&NUMPRTS 


&NUMPRTS 


Explanation: Variable symbol &NUMPRTS specifies the 
maximum number of physical printers HASP may use to 
print the printed output of jobs. HASP supports 1403 
and 3211 printers. The specification must be an 
integer greater than zero. 


Default: &NUMPRTS=2 


Notes: 

Te Tf HASP initialization finds more than &NUMPRTS 
1403 and 3211 printers, it writes to operator 
the message 

MAXIMUM OF &NUMPRTS PRINTER(S) EXCEEDED 
and continues normally, uSing as printers only 
the &NUMPRTS printers with lowest unit addresses. 

2. Regardless of the number specified for &NUMPRTS, 
HASP will use only those 1403 and 3211 printers 
which are operational (as shown by a TIO) or 
on-line (for M65MP only) when HASP is started. 

3. Handling of special forms by printer, the 
optional 1403 UCS buffer, and the 3211 UCS and 
Forms Control buffers is explained as part of 
the $T operator command. 


4. This variable influences the size of the HASP 
checkpoint record; see Note 2 of variable 
&MAXJOBS. 
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&NUMPUNS 


&NUMPUNS 


Explanation: Variable symbol &NUMPUNS specifies 
the maximum number of physical punches which will 
be used by HASP to punch the punched output of jobs. 
HASP supports 2540, 2520, and 1442 card punches. 

The specification must be an integer greater than 
Or equal to zero. 


Default: &NUMPUNS=1 


Notes: 


If HASP initialization finds more than &NUMPUNS 
2540, 2520 and 1442 punches, it writes to 
operator the message 

MAXIMUM OF &NUMPUNS PUNCH(S) EXCEEDED 
and continues normally, using as printers only 
the &NUMPUNS punches with lowest unit addresses. 
Regardless of the number specified for &NUMPUNS, 
HASP will use only those 2540, 2520 and 1442 
punches which are operational (as shown by a 
TIO) or on-line (for M65MP a..ly) when HASP is 
started. 
If &NUMPUNS=0, parameter &ACCTNG should be 
set to NO. 
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&NUMRDRS 


&NUMRDRS 


Explanation: Variable symbol &NUMRDRS specifies the 
maximum number of physical card readers HASP may use 
to read OS job streams. HASP supports 2540 and 2501 
card readers. The specification must be an integer 
greater than zero. 


Default: &NUMRDRS=1 


Notes: | 

i If HASP initialization finds more than &NUMRDRS 
2540 and 2501 card readers, it writes to oper- 
ator the message 

MAXIMUM OF &NUMRDRS READER(S) EXCEEDED 

and continues normally, using as readers only 
the &NUMRDRS readers with lowest unit addresses. 

2 Regardless of the number specified for &NUMRDRS, 
HASP will use only those 2540 and 2501 readers 
which are operational (as shown by a TIO) or 
on-line (for M65MP only) when HASP is started. 
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&NUMRJE 


Notes: 


&NUMRJE 


Explanation: Variable symbol &NUMRJE specifies the 
largest remote terminal identification number 

(nn in RMTnn) and thus the number of remote terminal 
definitions which are to be used by the generated 
HASP System. The specification must be an integer 
between 0 and 99 inclusive. 


Default: &NUMRJE=&NUMLNES 


l. See also the HASPGEN variable RMTnn. 

2 If this variable is not specified and if 
&NUMLNES is specified as an integer greater 
than zero, the first &NUMLNES remote terminal 
definitions RMTnn are used by the generated 
HASP System, whether they are specified 
explicitly or by default. 
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&NUMTGV 


&NUMTGV 


Explanation: Variable symbol &NUMTGV specifies the 
number of units (track groups) into which each SPOOL 
volume will be divided for HASP allocation purposes. 
The specification must be a positive integer no 
greater than the number of tracks on the SPOOL device 
with the fewest tracks. 


Default: &NUMTGV=400 


Notes: 
if The user should decide upon the number of tracks 


he requires in a track group and then divide by 
that number the total number of tracks (except 
alternate tracks) on a typical SPOOL device type 
at the installation. For example, to obtain a 
track group size of five tracks on a 2311, the 
division would yield a quotient of 400; the user 
would specify &NUMTGV=400. If the same instal- 
lation occasionally used a 2314 as a SPOOL 
device, the track group size for the 2314 would 
automatically become ten tracks. 

Specifying a large &NUMTGV may require increasing 
the value of &BUFSIZE. | 
For each SPOOL volume it finds, HASP initializa- 
tion calculates number of tracks per group by 
dividing the total number of tracks on the volume 
by &NUMTGV. It then marks unavailable all track 
groups which lie partially or wholly outside 

the first extent of data set SYS1.HASPACE on 

that volume. HASP initialization also computes 
the number of HASP buffers of length &BUFSIZE 
which will fit on a track of the SPOOL volume 

for each SPOOL volume mounted. 
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HAS P 


&NUMTPBF 


&NUMTPBF 


Explanation: Variable symbol &NUMTPBF specifies 
the number of HASP Teleprocessing buffers for HASP 
Remote Job Entry to be assembled into the generated 
HASP system. The specification must be an integer 
greater than or equal to zero. 


Default: &NUMTPBF=&NUMLNES 


Notes: 

Le Each signed-on HASP Multi-Leaving terminal re- 
quires at least two HASP Teleprocessing buffers; 
each other signed-on terminal requires at least 
one buffer. If &NUMTPBF is specified too small, 

- HASP RJE may not work correctly. | 

2% See also parameters &TPBFSIZ and &MLBFSIZ. 
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HAS P : : &NUMTPES 


&NUMTPES 


Explanation: Variable symbol &NUMTPES specifies 
the maximum number of tape drives HASP may use 
Simultaneously to read OS job streams. The speci- 

fication must be an integer greater than or equal 
to zero. 


Default: &NUMTPES=1 


Notes: 

i If &NUMTPES=0 is specified, code required to 
Support tapes as readers is omitted from the 
generated HASP System. 

Des Since the operator specifies a unit address 
when issuing the start command to a tape drive 
(e.g., SS TPE1,182), there is rarely a need to 
specify for &NUMTPES a number greater than one. 

3% Tapes should be equivalent to the JCL specifi- 
cation LABEL=(1,NL) ,DCB=(RECFM=FB,LRECL=80, 
BLKSIZE=nnnnn) where nnnnn is not greater than 
(lO*&BUFSIZE)/1ll. For seven-track tape, use 
the additional DCB specification DEN=2,TRTCH=C. 
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HAS P 


&NUMTPPR 


&NUMTPPR 


Explanation: Variable symbol &NUMTPPR specifies the 
maximum number of HASP Remote Terminal (including Multi- 
Leaving) printed-output streams that can simultaneously 
be active. The specification must be an integer greater 
than or equal to zero. | 


Default: &NUMTPPR=&NUMLNES 


Notes: 
A ie If any remote terminal is to receive printed 
output, &NUMTPPR must not be zero. 
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HAS P 


&NUMTPPU 


&NUMTPPU . 


Explanation: Variable symbol &NUMTPPU specifies the 
maximum number of HASP Remote Terminal (including 
Multi-Leaving) punched-output streams that can 


Simultaneously be active. The specification must 
@ an integer greater than or equal to zero. 
Default: &NUMTPPU=&NUMLNES 


Notes: 
Ls If any remote terminal is to receive punched 
output, &NUMTPPU must not be zero. 
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HAS P 


&NUMTP RD 


&NUMTPRD 


Explanation: Variable symbol &NUMTPRD specifies the 
maximum number of HASP Remote Terminal (including 
Multi-Leaving) input streams that can simultaneously 
be active. The specification must be an integer 
greater than or equal to zero. 


Default: &NUMTPRD=&NUMLNES 


Notes: 

i If any remote terminal is to read cards (including 
the /*SIGNON and /*SIGNOFF control cards) &NUMTPRD 
must not be zero. 
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H AS P 


SNUMWTOQ 


&NUMWTOQ 


Explanation: Variable symbol &NUMWTOQ specifies 
the number of message buffers to be provided in 


HASP. 


The specification must be an integer greater 


than two. 


Default: &NUMWTOQ=15 


Notes: 


1. 


2. 


If &NUMCONS is specified greater than ZexXo, 
additional message buffers are needed. 

If Remote Job Entry is used, more message 
buffers are needed. This is especially true 
with console support for MULTI-LEAVING 
terminals. 

Serious system degradation can be caused by 
specifying too few message buffers. 

During periods of high console activity, when 
no message buffers are available, certain non- 
critical HASP messages will be discarded rather 
than delaying the associated process. These 
include certain RJE oriented messages (such 

as communication line error messages), execution 
time/line/card excession messages (continued 
excession will be noted when a message buffer 
becomes available), and certain I/O error mes- 
Sages on HASP-controlled devices. Additionally, 
when no message buffers are available in a sys- 
tem in which &NUMCONS is greater than zero, 
messages from the OS error task are queued only 
to a depth of one which can result in the loss 
of some of these messages. 
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HAS P 


& OLAYLEV 


&OLAYLEV 


Explanation: Variable symbol SOLAYLEV specifies a 
HASP overlay level to be used for assembly of the 
various HASP control sections. Any potential overlay 
code defined (by the SOVERLAY macro) with a residence 
factor greater than &OLAYLEV will be assembled as 
resident code rather than overlay code. The specifi- 
cation for SOLAYLEV must be an integer between 0 and 


15, 


inclusive. 


Default: &OLAYLEV=15 


Notes: 


HASP uses only residence factors 4, 8, 12 and (for 
HASP initialization only) 0. 

If sSOLAYLEV=15, all potential overlay code will 

be assembled as overlay code. 

If sOLAYLEV=0, all potential overlay code except 
that in HASP initialization will be assembled 

as resident code. HASP main storage requirements 
will be increased by approximately 24K over 

the case &OLAYLEV=15. | 
Regardless of the setting of SOLAYLEV, the instal- 
lation systems programmer may use control cards 
for the HASP Overlay Builder after the HASPGEN 
process is .complete to specify that a particular 
section of potential overlay code be made either 
resident code or overlay code. 
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HAS P 


&OREPSIZ 


&OREPSIZ 


Explanation: Variable symbol &OREPSIZ specifies the 
Size in bytes of a table in HASP to be used to hold 
REP data for true overlay code. The REPs associated 
with a particular section of true overlay code will 
be applied to that code every time it is brought into 
main storage from the HASP overlay library. The 
Specification for &OREPSIZ must be either 0 or an 
integer not less than 10. 


Default: &sOREPSIZ=0 


Notes: | 

1. Bach entry in the HASP Overlay REP table consists 
of 8+n bytes (2<ns< 256) where n is the number 
of contiguous bytes to be changed in a section 
of overlay code. 

2. The table is used only if the operator specifies 
to HASP initialization that REPs are to be used 
and if some of the REPs are for sections of true 
overlay code, 

3 If the HASP Overlay REP table is too small to 
handle all true overlay REPs, HASP initialization 
writes to operator the message 

OVERLAY REPPING ERROR | 
and HASP quiesces. 
4, See also Section 6.4 of this manual. 
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&OSC(n) 
H AS P 


&OSC (n) 


Explanation: Subscripted variable symbols &0SC(n) 
specify OS job classes. A job selected by HASP 
logical partition n will be submitted to OS with the 
job class &O0SC(n). Each specification must be a 
Single unique letter between A and O, inclusive. 

No two specifications may be the same. 


Default: &OSC(1)=A 
&O0SC (2) =B 
&OSC (3) =C 
&OSC (4) =D 
&OSC (5)=E 
&OSC (6) =F 
&OSC (7)=G 
&OSC (8) =H 
&OSC (9) =I 
&OSC (10) =Jd 
&OSC (11)=K 
&OSC (12) =L 
&O0SC (13) =M 
&OSC (14) =N 
&OSC (15) =0 


Notes: | 
Ls Only the first &MAXPART specifications, &05C (13 
through &OSC(&MAXPART) will be used. 
Bs In an MVT system, HASP initialization issues 
the &MAXPART commands 
S INIT.HOSINIT&OSC (1) ,,,&OSC (1) 


3 S INIT.HOSINIT&OSC (&MAXPART) ,, ,&0SC (&MAXPART). 
3 In an MFT system, HASP initialization issues the 
| single command 
S INIT.ALL; 


thus the classes of the MFT partitions to be 
controlled by HASP must have already been defined. 
Each such partition must be defined with only 

one job class; that job class must match one and 
only one of the &MAXPART job classes &OSC(1), 

&OSC (&MAXPART) . 
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&OSINOPT 


&OSINOPT 


Explanation: Variable symbol &OSINOPT specifies inclu- 
sion or exclusion of the HASP OS Input Spooling option. 
The specification must be either YES or NO. If &OSINOPT= 
YES and a DD * (or DD DATA) statement specifies the DCB 
keyword, HASP will pass the DD statement and the data 
following it to the OS Reader/Interpreter; OS will 
perform input spooling. If &OSINOPT=NO, and for every 

DD * (or DD DATA) statement that does not specify the 
DCB= keyword, HASP will SPOOL the input data as usual. 


Default: &OS INOPT=NO 
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&OUTPOPT 


&OUTPOPT 


Explanation: Variable symbol sOUTPOPT specifies 

the action to be taken when a job exceeds its esti- 
mated print lines or punched cards of output. The 
specification must be one of the integers 0, 1 or 

2. For &OUTPOPT=2, output excession causes the job 
to be cancelled with a dump. For &sOUTPOPT=1, output 
excession causes the job to be cancelled without a 
dump. For sOUTPOPT=0, output excession does not 
cause the job to be cancelled. 


Default: s&OUTPOPT=0 


Notes: 

ie Regardless of the specification for &OUTPOPT, 
output excession causes messages to be written 
to the operator. See also Notes 1 and 2 of 
&OUTXS. 

2. If &sOUTPOPT=2 is specified, users should use 
SYSUDUMP or SYSABEND DD cards if a core dump 
is desired on output excession. 
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HAS P 


SOUTXS 


$OUTXS 


Explanation: Ordinary symbol $SOUTXS specifies 
the interval, in print lines/punched cards, at 
which messages will be written to the operator 
informing him that a job's print line count or 
punch card count has been exceeded. The speci- 
fication must be an integer greater than zero. 


Default: SOUTXS=2000 


Notes: 

is The first print line excession message will 
be written to the operator when the job's 
estimated print line count has been exceeded. 

Zi The first punched card excession message 
will be written to the operator when the 
job's estimated punched card count has been 
exceeded. 
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HAS P 


&PID (n) 


~ &PID(n) 


Explanation: Subscripted variable symbols &PID(n) 
Specify the identifiers to be used with the HASP 
logical partitions. Each specification must be 

a unique l- or 2-character string. 


Default: &PID(1)=1l 
&PID (2) =2. 
&PID (3)=3 
&PID(4)=4 
&PID (5) =5 
&PID (6) =6 
&PID (7) =7 
&PID (8) =8 
&PID (9) =9 
&PID(10)=10 
&PID(11)=11 
&PID (12) =12 
&PID (13)=13 
&PID(14)=14 
&PID(15)=15 


Notes: je * 
lL. Only the first &MAXPART specifications, &PID(1l) 
through &PID(&MAXPART), will be used. 
2% The identifiers &PID(n) are used in messages 
to and commands from the operator. For example, 
when an operator uses the set command $T Imm,list 
he is referring not to logical partition mm but 
to logical partition n, where &PID (n) =mm. 
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&PRI (n) 


&PRI(n) 


Explanation: Subscripted variable symbols &PRI(n) 
specify OS job priorities. A job selected by HASP 
logical partition n will be submitted to OS with the 
job priority &PRI(n). Each specification must be 

an integer between 1 and 15, inclusive. 


Default: #&PRI(1)=7 


&PRI (2) =7 
&PRI (3)=7 
&PRI (4) =7 
&PRI (5) =7 
&PRI (6) =7 
&PRI (7) =7 
&PRI (8) =7 
&PRI (9) =7 
&PRI (10)=7 
&PRI (11) =7 
&PRI (12) =7 
&PRI (13) =7 
&PRI (14) =7 
&PRI (15) =7 


Notes: 


Lis 


The defaults are all the same as &XZPRTY. This 
allows the HASP Execution Task Monitor to regu- 
late all job steps under the control of HASP. 
See also parameters &XZPRTY and &MONINTV. 

These parameters have no effect in MFT. 

The priorities defined by &PRI(n) affect only 
OS execution. The priority of a job in the 
HASP Job Queue is determined by parameters 
&RPRT (m), &RPRI(m), &XLIN(m), and &XPRI(m). 
Only the first &MAXPART specifications, &PRI(1) 
through &PRI(&MAXPART), will be used. 
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HAS P 


SPRICONA 


$PRICONA 


Explanation: Ordinary symbol SPRICONA specifies the 
unit address of a 1052, 3210, 3215, 1443, or 1403 to 
which HASP will issue a SIO in the event of a catas- 
trophic error. The message HASP writes to this device 
1s: | 
HASP CATASTROPHIC ERROR. CODE=xxx. 

The specification must be a valid unit address. 


Default: SPRICONA=01F 


Notes: | 

i When HASP is operating with M65MP in a 2-CPU 
multiprocessor environment, the device specified 
by SPRICONA must be operational to both CPUs 
when a HASP catastrophic error occurs. 
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HAS P 


SPRIDCT 


$SPRIDCT 


Explanation: Ordinary symbol $PRIDCT specifies the 
number of print lines to appear on each HASP job 
separator page for local printers. The specification 
must be an integer greater than or equal to zero. If 
the specification is zero, no separator page will be 
produced on local printers. 


Default: SPRIDCT=61 


Notes: 
i The equivalent HASPGEN parameter for remote 
terminal printers is STPIDCT. 
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HAS P 


& PRIHIGH 


&PRIHIGH 


Explanation: Variable symbol &PRIHIGH specifies a 
HASP priority to be associated with the HASP Priority 
Aging feature. A job will not be priority-aged if 
its HASP priority is (or becomes) greater than or 
equal to &PRIHIGH. The specification must be an 
integer between 0 and 15, inclusive. 


Default: &PRIHIGH=10 


Notes: 
1. If &PRIRATE=0, parameter &PRIHIGH is not used. 
2 See also parameters &PRIRATE and &PRILOW. 


HASPGEN Parameters - Page 7.1.65 
374 


HAS P 


& PRI LOW 


&PRILOW 


Explanation: Variable symbol &PRILOW specifies a 

HASP priority to be associated with the HASP Priority 
Aging feature. A job will not be priority-aged by 
HASP unless its HASP priority is initially at least 
&PRILOW. The specification must be an integer between 
0 and 15, inclusive. 


Default: &PRILOW=5 


Notes: 
Is If &PRIRATE=0, parameter &PRILOW is not used. 
Zs See also parameters &PRIRATE and &PRIHIGH. 
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HAS P 


&PRIRATE 


&PRIRATE 


Explanation: Variable symbol &PRIRATE specifies the 
amount by which a job's HASP priority will be incre- 
mented in 24 hours by the HASP Priority Aging feature. 
For example if &PRIRATE=3 then a job's priority will 

be incremented by one for every eight hours it remains 
in the system. But a job's priority will not be incre- 
mented unless it is at least &PRILOW; nor will a job's 
priority be incremented above &PRIHIGH. The specifi- 
cation must be an integer greater than or equal to 
zero. If zero is specified, Priority Aging is excluded 
from the generated HASP system. 


Default: &PRIRATE=0 





Notes: : 

Ls If &PRIRATE=0, parameters &PRILOW and &PRIHIGH 
are not used. 

2. See also parameters &RPRT(n), &RPRI(n), &XLIN(n), 
and &XPRI(n). 

3. If a job's priority is specified on the /*PRIORITY 


control card, the job will be priority-aged if 
its priority is eligible. 
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HAS P 


SPRTBOPT 


$PRTBOPT 


Explanation: Ordinary symbol $PRTOPT specifies the 
printer buffering option to be used for local HASP 

printers. The specification must be either 1] (for 

Single buffering) or 2 (for double buffering). 


Default: SPRTBOPT=2 
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HAS P 


&PRTRANS 


&PRTRANS 


Explanation: Variable symbol &PRTRANS specifies 
translation for lines of print. The specification 
must be either YES or NO. 


Default: &PRTRANS=YES 


Notes: 

ie If &PRTRANS is specified as YES, each line to 
be printed by HASP is first translated. Trans- 
lation changes lower-case letters to upper-case 
letters and characters invalid on a PN train to 
blanks. 

2. If any print train is to’ be used on any HASP- 
controlled printer which has characters not 
equivalent to those on a PN train or a Pll train, 
&PRTRANS must be specified as NO. 


378 


HAS P &PRTUCS 


&PRTUCS 


Explanation: Variable symbol &PRTUCS specifies the 
name of the print chain or print train which HASP 
initially assumes is mounted on every local 1403 
printer SYSGENed with the UCS feature, and on every 
local 3211 printer. The UCS identifier can be modi- 
fied by the operator individually by printer. The 
specification should be either AN, HN, PN, QN, RN, 
UN, All, H11, Pll, Ull, or 0. 


Default: &PRTUCS=0 


Notes: 

i A specification of zero causes HASP to bypass 
the UCS loading procedure on all local printers 
until the UCS type of each printer is specified 
by the operator. 

2. Only the first character of &PRTUCS is interro- 
gated. That is to say, an AN specification is 
equivalent to an All specification, an H1l 
specification is equivalent to an HN specifica- 
tion, etc. 

35 If a UCS specification is encountered which is 
not valid for the type of printer being addressed, 
the UCS loading procedure will be bypassed. 





4, The UN and Ull specifications are provided for 
installation use to support other type of print 
chains. 
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HAS P 


SPUNBOPT 


$PUNBOPT 


Explanation: Ordinary symbol S$PUNBOPT specifies the 
punch buffering option to be used for local HASP 
punches. The specification must be either 1 (for 
Single buffering) or 2 (for double buffering). 


Default: SPUNBOPT=1 
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HAS P 


&RDR 


&RDR 


Explanation: Variable symbol &RDR specifies the 
unit address of a pseudo-2540 reader to be used with 
HOSRDR to supply jobs to OS. The specification must 
be a valid unit address which has been specified at 
SYSGEN time as a pseudo-2540 reader. 


Default: & RDR=0FC 
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HAS P 


& RDRPART 


&RDRPART 


Explanation: Variable symbol &RDRPART specifies for 
MFT systems the identifier field of an OS START 
command issued by HASP initialization for the OS 
reader/interpreter HOSRDR. The complete START command 
is 

S HOSRDR.&RDRPART, &RDR. 
The specification must be a valid identifier field 
for an OS START reader command, as described in the 
OS Operator's Guide. 


Default: &RDRPART=S 


Notes: 
Ls If HASP initialization detects an MVT systen, 
this parameter is not used. 
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| ¢SREPRDR 
HASP 


SREPRDR 


Explanation: Ordinary symbol S$REPRDR specifies the 
unit address of a physical 2540 or 2501 card reader 
from which HASP initialization will read REP cards 
if requested by the operator. The specification 
must be a valid unit address. 


Default: SREPRDR=00C 


Notes: 

Is When REP cards are to be read and HASP is 
operating with M65MP in a 2-CPU multiprocessor 
environment, the device specified by SREPRDR 
must be operational to both CPUs. 


HASPGEN Parameters - Page 7.1.74 


383 


HAS P 


SREPWTR 


$REPWTR 


Explanation: Ordinary symbol SREPWTR specifies the 
unit address of a physical 1403 or 1443 on which 
each REP card read is to be printed, if printing 

of REP cards is requested by the operator. The 
specification must be a valid unit address. 


Default: SREPWTR=00E 


Notes: 

Le When REP cards are to be printed and HASP is 
operating with M65MP in a 2-CPU multiprocessor 
environment, the device specified by SREPWTR 
must be operational to both CPUs. 
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HAS P 


&RESCORE 


&RESCORE 


Explanation: Variable symbol &RESCORE specifies a 
storage size, in multiples of 1024 bytes. HASP will 
always issue a GETMAIN for additional storage for HASP 
buffers; all such storage but &RESCORE*1024 bytes will 
be used for buffers. 


The specification must be an integer greater than or 
equal to zero. 


Default: &RESCORE=0 
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HAS P 


&RJOBOPT 


& RJOBOPT 


Explanation: Variable symbol &RJOBOPT specifies 
whether or not an illegal HASP JOB card is to prevent 
execution of the associated job. The specification 
must be either YES or NO. 


Default: &RJOBOPT=NO 


Notes: 

If &RJOBOPT=YES and HASP reads a JOB card whose 
accounting field does not match the specifica- 
tions required by HASP, the job is flushed by 
HASP and an appropriate message is written to 
the operator. 
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ae 
» 
on 
a) 


RMTnn 


Code Letters 


nn 


mm 


oTe) 
PP 
1i 


ll 


Explanation: 


RMTnn 


Ordinary symbols RMTnn specify the 


characteristics of remote terminals to be used with 
Terminals must be defined 
consecutively, starting with RMT0O1. Each specifica- 
tion must be a 14-character string of the form 
RMTnn=mmooppiillwtdf 
where the letters represent the following: 


HASP Remote Job Entry. 


Range 


01-99 
OL-99 


00-99 
00-99 
00-15 
00-15 


0-6 


Line Number 


Description 


Remote Number 


assignment) 


(**indicates /*SIGNON 


Print Routing (Remote Number) 


Punch Routing (Remote Number) 


Priority Increment for this Remote 


Priority Limit for this Remote 


a0) 
K 
bt 
eo 
ct 
0) 
Ky 
= 
aa 
Ou. 
ct 
> 


Data Format 


387 


Nu 


WN Fr © 


as follows: 

80 characters 
100 characters 
120 characters 
132 characters 
144 characters 
150 characters 

96 characters 


as follows: 

1009, 2770 

1978, 2780, 7702 

System 360/20 Sub-model 2 
System 360/20 Sub-model 5 
System 360/25, 30, 40, 
50, etc. 

1130 

System/3 


as follows: 


Unblocked fixed length 
Blocked fixed length 
Unblocked variable. length 
Blocked variable length 
(Note - this should be 
used for all 1978, 2770, 
and 2780 terminals.) 
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4 = Programmable Interface 
(Note - this should be 
used for all STR 20 and 
BSC MULTI-LEAVING inter- 
faces.) 


Terminal Features as follows: 
0-3 2770 Terminal Features 


Buffer | 
f Expansion Transparency Notes 


0 No No w must be O, 1, 
2or 6 
1 No Yes w must be 0, lL 
2or 6 
2 Yes — No 
3 Yes Yes 
0-7 2780 Terminal Features 
Horizontal Multiple 
£ Format Control Record Feature Transparency 
0 No | No No 
il No No Yes 
2 No Yes No 
3 No Yes Yes 
4 Yes No No 
5 Yes No Yes 
6 Yes : Yes No 
7 Yes Yes Yes 
0-3 - MULTI-LEAVING Terminal Features 
Console 
£ Support Transparency 
0 No No 
i No © Yes 
2 Yes No 
3 Yes Yes 


Default: RMTnn=**nn0000153131 


Notes: Oe 

is Parameter &NUMRJE must specify the number of speci- 
fications RMTnn to be included in the generated 
HASP system. 
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HAS P 


No two specifications RMTnn may specify the same 
line number (mm). If ** is specified instead of 
a line number for mm, the associated remote ter- 
minal may connect to HASP via any suitable line. 
HASP will logically connect the terminal with the 
line when it recognizes the /*SIGNON control card. 
If line number is specified explicitly, the asso- 
Ciated terminal need not use a /*SIGNON card. 

The line number specification mm refers to line 
Specification LINEmm, which in turn specifies 

the unit address of the line. 

For print and punch routing, a specification of 

00 causes output from jobs submitted at the Remote 
Terminal to be printed/punched locally, unless 
re-routed. 

Priority increment is the value to be added to the 
priority of a job submitted from the Remote 
Terminal. 

Priority limit is the maximum value of priority 
for any job submitted from the Remote Terminal. 

If any MULTI-LEAVING workstation is to utilize 
more than one reader, printer or punch, see 
Section 12.16 for additional information. 
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HAS P 


SRPRBOPT 


-$RPRBOPT 


Explanation: Ordinary symbol $RPRBOPT specifies the 
printer buffering option to be used for all printers 
at HASP Remote Terminals. The specification must be 
either 1 (for single buffering) or 2 (for double 
buffering). | | 


Default: SRPRBOPT=1 


Notes: 
1. The specification refers to HASP regular buffers, 
not to HASP Teleprocessing buffers. 
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HAS P 


&RPRI (n) 


&RPRI(n) 


Explanation: Subscripted variable symbols &RPRI (n) 
Specify tentative job priorities corresponding to 
intervals defined by subscripted variable symbols 
&RPRT(n). If a user specifies in the accounting 
field of his job card an estimated execution time 
of t minutes, the job's tentative priority will 
be &RPRI(n) where 

&RPRT (n-1)<t<&RPRT(n). 
Fach specification must be an integer between 0 and 
15 inclusive. 


Default: &RPRI(1)=9 
&RPRI (2) =8 
&RPRI (3) =7 
&RPRI (4) =6 
&RPRI (5) =5 
&RPRI (6) =4 
&RPRI (7) =3 
&RPRI (8) =2 
&RPRI (9)=1 


Notes: 

Ds The values &RPRI(n) will normally be in 
Opposite order from the subscripts n. 

25 See also Notes 1 and 2 for &RPRT(n). 
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HAS P 


&RPRT (n) 


&RPRT(n) 


Explanation: Subscripted variable symbols 
&RPRT(n) specify estimated execution times in 
minutes. If a user specifies in the accounting 
field of his job card an estimated execution time 
of t minutes, and if t satisfies the relation 
&RPRT (n-1) <ts&RPRT (n) 
then &RPRI(n) will be the tentative priority of 
the job. If t is less than &RPRT(1) or greater 
than &RPRT(9), value &RPRI(1) or zero will be 
the tentative priority of the job. Each A hecho aoa 
cation must be an pe ad between 1 and X'FFFFFF' /60 
inclusive. 


Defaults: &RPRT(1)=2 
7 &RPRT (2) =5 
&RPRT (3) =15 

&RPRT (4) =X'FFFFFF' /60 

&RPRT (5) =X'FFFFFF' /60 

&RPRT (6) =X'FFFFFF '/60 

&RPRT (7) =X'FFFFFF' /60 

&RPRT (8)=X'FFFFFF' /60 

&RPRT (9) =X'FFFFFF' /60 


Notes: 
Ls Priority &RPRI(n) is overridden by HASP 
control card /*PRIORITY. 
2s The tentative priority defined above is adjusted 


according to &XLIN(m) and the estimated print 
lines specified in the accounting field of 
the user's JOB card. If the user estimated 
p print lines, and if p satisfies the relation 
&XLIN (m) <p<&XLIN (m+1) 
then the tentative priority is reduced by m. 
35 The values &RPRT(n) should be in the same 
order as the subscripts n. 
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SRPUBOPT 


$RPUBOPT 


Explanation: Ordinary symbol S$RPUBOPT specifies the 
printer buffering option to be used for all punches 
at HASP Remote Terminals. The specification must 

be either 1 (for single buffering) or 2 (for double 
buffering). 


Default: S$RPUBOPT=1 


Notes: 
i The specification refers to HASP regular buffers, 
not to HASP Teleprocessing buffers. 
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toast a &ROENUM 


& RQENUM 


Explanation: Variable symbol &RQENUM specifies the 
number of WTOR reply buffers to be provided in the 
generated HASP system. The specification must be 
an integer greater than zero. | 


Default: &RQENUM=5 


Notes: | 

Ls This parameter is ignored if &NUMCONS=0. 

2. If &NUMCONS is not specified as zero, no more 
than &RQENUM replies can be outstanding at any 
time. | | 
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HAS P 


&SIZ2260 


&S1Z2260 


Explanation: Variable symbol &S1I22260 specifies 
screen width in characters for local 2260s (attached 
via 2848) to be used as HASP operator consoles. 

The specification must be either 0, 40, or 80. If 

0 is specified, support for local 2260s and local 
1053s (attached via 2848) will be excluded from the 
generated HASP system. 


Default: &SI2Z2260=0 


Notes: 
1. This parameter is not used if &NUMCONS=0. 
2% See also parameter &SPD2260. 
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HAS P 


&SPD2260 


— &SPD2260 


Explanation: Variable symbol &SPD2260 specifies roll 


rate in hundredths of a second for local 2260s (attached 
via 2848) to be used as HASP operator consoles. If 

new messages are pending for display on a HASP 2260 
console, they will be displayed (and old messages will > 
be deleted, if the screen is full) at the rate of one 
message every &SPD2260/100 seconds. 


Default: &SPD2260=50 


Notes: 
A ie This parameter is not used if oes 0 or if 
&SIZ2260=0. 
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&SPOLMSG 


Explanation: Variable symbol &SPOLMSG specifies the 
number of physical records in the first extent of 
SYS1.HASPACE on SPOOL1 which are to be reserved for 
holding operator and HASP messages for HASP Remote 
Terminals. Each physical record is capable of holding 
one or more messages for a single remote terminal. 
Messages are held if they are directed to: 


. any terminal not signed on; 

» any signed-on hardware terminal which is cur- 
rently processing an input or output stream; 

. any signed-on computer terminal that is not a 
Multi-Leaving terminal with a console. 


If a message is to be held but no space is available 
to hold it, the message is thrown away without operator 
notification. 


The specification for &SPOLMSG must be an integer 
greater than or equal to zero. If &SPOLMSG is speci- 
fied as zero, no messages will be sent to hardware 
terminals. | 


Default: &SPOLMSG=10* &NUMRJE 


Notes: 

I Only the SDM command can generate messages to a 
terminal not Signed on. 

2% For signed-on terminals, messages are generated 


for job-on-reader, by $DM, and as responses to 
commands from the terminal. 

a Each message to a terminal (except to a Multi- 
Leaving remote defined with a console) is 
held until it can be printed, or until HASP is 
restarted. 
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HAS P 


&STRCPU 


&STRCPU 


Explanation: Variable symbol &STRCPU specifies inclu- 
sion or exclusion in the HASP Remote Terminal Access 
Method of Remote Job Entr; support for the System/360 
Model 20 with a Synchronous Transmit-Receive (STR) 
adapter and the associated HASP Remote Terminal program. 
The specification must be either YES or NO. 


Default: &STRCPU=NO 
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HAS P 


&STR1978 


&STR1978 


Explanation: Variable symbol &STR1978 specifies inclu- 
Slon or exclusion in the HASP Remote Terminal Access 
Method of Remote Job Entry support for Synchronous 
Transmit-Receive (STR) hardware terminals such as the 
1978. The specification must be either YES or NO. 


Default: &STR1978=NO 
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HAS P 


& TIMEOPT 


&TIMEOPT 


Explanation: Variable symbol &TIMEOPT specifies the 
action to be taken when a job's estimated execution 
time is exceeded. The specification must be one of 
the integers 0, 1, 2 or 4. For &TIMEOPT=4, the job's 
time limits will not be monitored. For &TIMEOPT=2, 
time excession causes the job to be cancelled with a 
dump. For &TIMEOPT=1, time excession causes the job 
to be cancelled without a dump. For &TIMEOPT=2, 
&TIMEOPT=1, or &TIMEOPT=0, time excession causes 
messages to be written to the operator. 


Default: é&TIMEOPT=4 


Notes: | 
1. See also Notes 1 and 2 of &ESTIME, which apply 
for &TIMEOPT=0, &TIMEOPT=1, and &TIMEOPT=2. 
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STIMEXS 


$TIMEXS 


Explanation: Ordinary symbol $TIMEXS specifies 
the interval, in minutes, at which messages will 
be written to the operator informing him that a 
job's execution time is exceeded. The specifica- 
tion must be an integer greater than zero. 


Default: STIMEXS=1 


Notes: 

ls The first time excession message 1S written 
to the operator when the job's estimated 
execution time has been exceeded. 


2% If &TIMEOPT is specified greater than 2, 
STIMEXS is not used. 
3. See also Note 2 of SESTIME. 
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HAS P 


&TPBFSIZ 


&TPBFSIZ 


Explanation: Variable symbol &TPBFSIZ specifies 
the size in bytes of each HASP Teleprocessing 
buffer. The specification must be an integer not 
less than 328 if &BSC2770=NO and &BSC2780=NO, 

and otherwise not less than 400. 


Default: é&TPBFSIZ=400 


Notes: 


Ls 


The value of &TPBFSIZ is the maximum size of 

any HASP Teleprocessing buffer. See also 
parameter &MLBFSIZ, which may never be specified 
larger than &TPBFSIZ. 

The HASP Remote Terminal program for the 
System/360 Model 20 with an STR communications 
adapter (HRTPSM20) uses a teleprocessing buffer 
size of &TPBFSIZ; all other HASP Remote Terminal 
programs are Multi-Leaving programs, and use 
&MLBFSIZ. 7 

The parameter &TPBFSIZ is specified only once, 
at HASPGEN time; it is conveyed automatically 

to the requisite Remote Terminal programs by 
HASPGEN. | | : 

See also the notes for &MLBFSIZ. 
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HAS P 


STPIDCT 


$TPIDCT 


Explanation: Ordinary symbol $TPIDCT specifies the 
number of print lines to appear on each HASP job 
separator page for jobs whose printed output is directed 
to any HASP Remote Terminal. The specification must 

be an integer greater than or equal to zero. If the 
Specification is zero, no separator page will be pro- 
duced on remote printers. 


Default: STPIDCT=6 


Notes: 
i. The equivalent HASPGEN parameter for local printers 
is SPRIDCT. 
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&TRACE 


&TRACE 


Explanation: Variable symbol &TRACE specifies inclu- 
sion or exclusion of a facility for event-tracing 

and statistics-gathering in the generated HASP system. 
It also specifies the nuitber of entries to be genera- 
ted in the HASP trace table. The specification must 
be an integer greater than or equal to zero. 


Default: &TRACE=0 


Notes: : 

Li. Inclusion of the HASP Trace facility causes the 
OS program interrupt exit (SPIE) mechanism to 
work incorrectly. For this reason, the HASP 
Trace should not be included in any generated 
HASP system designed for normal production. 

2. The &TRACE option is independent of the &DEBUG 
option. 
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HAS P &USASCI! 


&USASCII 


Explanation: Variable symbol &USASCII specifies inclu- 
sion or exclusion in the HASP Remote Terminal Access 
Method of the capability to use USASCII line control 
characters as well as EBCDIC line control characters. 
If any line specification LINEmm for a BSC line has 
value c set to 2, 3, 6 or 7, &USASCII should be set 

to YES; otherwise, &USASCII should be set to NO. 


Default: &sUSASCII=NO 
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HAS P 


SWAITIME 


$SWAITIME 


Explanation: Ordinary symbol $WAITIME specifies a 
time interval, in seconds. For hardware terminals, 
the HASP Remote Terminal Access Method will wait 
SWAITIME seconds. at the completion of processing of 
any input stream, printed output stream, or punched 
output stream, to allow the operator time to alter 

the normal sequence of Remote Job Entry operations. 
For example, the operator may wish to transmit another 
job to HASP after a previous job has finished printing 
rather than wait till the previous job has finished 
punching. 


The specification for SWAITIME must be an integer 
greater than zero. 


Default: SWAITIME=1 
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HAS P 


&WCLSREQ 


— &WCLSREQ 


Explanation: Variable symbol &WCLSREQ specifies optional 
requeueing for OS output classes specified by &WTRCLAS. 
The values assigned &WCLSREQ are effective only if 
&WIRPART=*. | 


If &WTRPART=*, then the HASP writer subtask (load module 
HASPWTR) processes jobs queued in the OS output queues 
defined by &WITRCLAS. At the end of processing a job 
whose output class is the nth character of &WTRCLAS, 
HASPWTR examines the nth character of &WCLSREQ. If the 
nth character of &WCLSREQ is *, HASPWTR deletes the 

job from the OS Job Queue. But if the nth character 

of &WCLSREQ is an OS Output class, HASPWTR requeues 

the job in the OS Output queue specified by the nth 
character of &WCLSREQ (which must be different from 

any class specified in &WTRCLAS). 


The specification must be a string of one to eight char- 
acters each of which is either * or a unique valid OS 
output class different from any specified in &WTRCLAS. 
If more characters are specified than were specified 

for &WTRCLAS, the excess characters are unused. 


Default: &WCLSREQ=*******x% 


Notes: 

de The output requeueing option is useful for providing 
an extra copy of a job's system messages to, for 
example, a conversational programming terminal. 

2% A requeued job is not referenced by HASP, but must 
be accessed by a standard OS Output Writer or other 
Suitable means. 

3% A requeued job may contain a mixture of system 
messages and sysout data sets of the same class, 
if the sysout data sets were spooled by OS (see 
HASPGEN parameter $$x). The module HASPWTR does 
not process the sysout data sets, but requeues the 
entire job containing them in the new class specified 
by &WCLSREQ. The system messages and sysout data 
sets are then available to a standard OS Output 
Writer which is processing the new class. 
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HASP 


Any DD statements in the system messages of a 
requeued job, which are originally coded as DD* 

or DD DATA and are not subject to OS spooling (see 
HASPGEN parameter &OSINOPT), are available to a 
Writer processing a &WCLSREQ class as DDS and 

DD CATA respectively. They are printed as DDS and 
DD CATA unless the Writer is programmed to change 
them to their original form. 
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HAS P 


&WTLOPT 


&WTLOPT 


Explanation: Variable symbol &s&WTLOPT specifies 
inclusion or exclusion of code to cause HASP to 
intercept the WTL SVC (SVC 36) and to add to a job's 
output any log messages associated with it. The 
messages will be written on the HASP System Log for 
the job. The specification for &WTLOPT must be either 
YES or NO. 


Default: &WILOPT=NO 


Notes: 

ie If &WTLOPT is set to YES and &NUMCONS is set 
non-zero, no messages will be recorded on the 
OS log data sets and the OS WRITELOG command 
must not be used. 

2. If &WTLOPT is set to YES and &LOGOPT is set to 
NO, all WTL messages will be thrown away. 
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HA SP 


&WTR 


&WTR 


Explanation: Variable symbol &WTR specifies the 
unit address of a pseudo-1403 printer to be used 

by a writer to retrieve from the OS Job Queue System 
Message Blocks (SMBs) for jobs controlled by HASP. 
The specification must be a valid unit address which 
has been specified at SYSGEN time as a pseudo-1403 
printer. % 


Default: &WTR=0FE 


Notes: 

1. The unit address assigned to this parameter must 
not be assigned a symbolic unit name at SYSGEN 
time, as described for other pseudo-1403 printers. 
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HAS P 


&WTRCLAS 


&WTRCLAS 


Explanation: Variable symbol &WTRCLAS specifies the 

OS System Output classes to be processed by HASP. 

The output writer started by HASP initialization (and 
selected by the &WTRPART Parameter) is intended to 
process only those System Message Blocks (SMBs) 

created by OS jobs submitted to and controlled by 

HASP. If other OS writers are to be used concurrently 
with the writer started by HASP, none of them may 
process any of the output classes specified in &WTRCLAS. 


The specification for &WTRCLAS must be one to eight 
unique characters that are valid OS output classes. 


Default: &WTRCLAS=HA 


Notes: | 

a HASP examines the MSGCLASS parameter of every 
JOB card it sends to OS. If MSGCLASS is not 
specified or is not one of the classes specified 
by &WTRCLAS, HASP adds the MSGCLASS parameter 
to the JOB card, using as a class the leftmost 
character of &WTRCLAS. 

2. If a job submitted to OS by HASP has certain 
errors on the JOB card, OS will fail the job and 
change its MSGCLASS to A. It is therefore 
recommended that class A be specified in &WTRCLAS. 
If class A is not specified and such an error 
happens, HASP may not operate correctly. 

33 See also HASPGEN parameter $Sx. 
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HAS P 


&WTRPART 


&WTRPART 


Explanation: Variable symbol s&WTRPART specifies the 
method HASP will use to retrieve from the OS Job 
Queue System Message Blocks for jobs controlled by 
HASP. | 


For &WTRPART=*, HASP initialization creates a subtask 


to interface eneeey between HASP and the OS Job 


Queue. 


If &WTRPART is not specified as * HASP initializa- 
tion starts an OS writer (using procedure HOSWTR) 
to interface between HASP and the OS Job Queue. [In 
particular, for MFT Sveteis HASP initialization 
issues the OS command 

S HOSWTR. &WIRPART, &WTR, , &WTRCLAS 


The specification for &WTRPART must be either * or, 
for MVT, any other character string of one to eight 
characters or, for MFT, a valid identifier for an 
OS START writer command , as described in the OS 


Operares. s Guide. 


Default: &s&WTRPART=* 


Notes: 

de For an OS MFT system, the default specification 
requires that, during SYSGEN, the SUPRVSOR macro 
include ‘ATTACH in the OPTIONS=keyword. 

2 If &WTRPART is not specified as *, it is 
recommended for an MFT system that HOSWTR 
be assigned the partition immediately below 
HASP in priority. That is, if HASP were to 
be assigned PO, &WTRPART would be specified as 
Pl. 
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&XBATCHC 


&XBATCHC 


Explanation: Variable symbol &XBATCHC specifies a 

list of job classes to be used with the HASP Execution 
Batch Scheduling feature. The specified classes are 
excluded from running jobs outside of Execution 

Batch Scheduling. The specification for &XBATCHC 

is a string of one to eight characters (letters and 
numbers) which specify valid unique HASP job classes. 

If &XBATCHC is left at its default, the generated 

HASP system will not include Execution Batch Scheduling. 


Default: &XBATCHC=[null string] 


Notes: 

ie For further information, see the section of this 
manual on the Execution Batch Scheduling feature. 

23 If &XBATCHC is not specified, then &XBATCHN is 
not used. 
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HAS P 


& XBATCHN 


&XBATCHN 


Explanation: Variable symbol &XBATCHN specifies the 
first five characters of the name of each OS job to 
be started internally by HASP when required for the 
execution of a user "job" under the HASP Execution 
Batch Scheduling feature. The specification must be 
a five-character string of which the first character 
is alphabetic or national and the remaining four 

are alphameric or national. 


Default: &XBATCHN=SSSSS$ 


Notes: 

i For further information, see the section of this 
manual on the Execution Batch Scheduling feature. 

Bis If &XBATCHC is specified, then HASP will reject 


all user submitted jobs whose jobnames start 
with the five characters & XBATCHN. | 
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&XLIN (n) 


Explanation: Subscripted variable symbols 
&XLIN(n) specify estimated line counts. If a 
user specifies in the accounting field of his 
job card an estimated line count of 1l=p/1000, 
then the tentative job priority computed on the 
basis of his estimated execution time will be 
reduced by n, where 

&XLIN (n) <p<&XLIN(n+1). 
Each specification must be an integer between 1 
and 16,777,215. &XLIN(9) must be 16,777,215. 


Default: &XLIN(1)=2000 
&XLIN (2) =5000 
&XLIN (3) =15000 
&XLIN (4) =X'FFFFFF' 
&XLIN (5) =X'FFFFFF' 
&XLIN (6) =X'FFFFFF'! 
&XLIN (7) =X'FFFFFF' 
&XLIN (8) =X'FFFFFF' 
&XLIN (9) =X'FFFFFF' 


Notes: 
The values &XLIN(n) must be in the same 
order as the subscript n. 


~~ 


2. See also Note 2 for &RPRT(n). 

33 These values are not used if the job uses a 
/*PRIORITY HASP control card. 

4. See also the description of &XPRI(n), used 


with &XLIN(n) to determine a job's printing 
priority. 
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&XPRI (n) 


&XPRI(n) 


Explanation: Subscripted variable symbols &XPRI(n) 
specify job priorities for printing which cor- 
respond to intervals defined by subscripted 
variable symbols &XLIN(n). If a user does not sup- 
ply a /*PRIORITY control card with his job, the 
job's priority is recomputed after execution based 
upon the actual number of print lines it produced. 
If the job produced p print lines then its priority 
for printing and punching will become &XPRI(n), 
where n is the smallest number for which 
ps&XLIN(n). 
Each specification must be an integer between 0 and 
15 


Default: &XPRI(1) 
&XPRI (2) 
&XPRI (3) 
&XPRI (4) 
&XPRI (5) 
&XPRI (6) 
&XPRI (7) 
&XPRI (8) 
&XPRI (9) 


lu unt tt bo tt 
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HAS P 


& XZMFTH 


&XZMFTH 


Explanation: Variable symbol &XZMFTH specifies the 

1spatching priority of the highest-priority MFT task 
to be included in the group of tasks analyzed by the 
HASP Execution Task Monitor. Each MFT HASP-controlled 
job step task without subtasks whose dispatching 
priority falls within the range &XZMFTL through &XZMFTH 
is examined by the HASP Execution Task Monitor every 
&MONINTV seconds. In order to balance the CPU utili- 
zation characteristics of these tasks, the Execution 
Task Monitor resets the dispatching priority of each 
of them to &XZMFTL and, if necessary, changes their 
order on the TCB ready chain. The specification for 
&XZMFTH must be one or two hexadecimal characters 
ranging from 00 to FF. 


Default: &XZMFTH=FF 


Notes: 

ds If &XZMFTH is specified as 00, Execution Task 
Monitor support for MFT is excluded from the 
generated HASP system. 

i If &XZMFTH is specified as 00 and &XZPRTY is 
specified as 0-1, then &MONINTV must be specified 
as 0. 
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&XZMFTL 


&XZMFTL 


Explanation: Variable symbol &XZMFTL specifies the 
dispatching priority of the lowest-priority MFT task 

to be included in the group of tasks analyzed by the 
HASP Execution Task Monitor. Each MFT HASP-controlled 
job step task without subtasks whose dispatching 
priority falls within the range &XZMFTL through &XZMFTH 
is examined by the HASP Execution Task Monitor every 
&MONINTV seconds. In order to balance the CPU utiliza- 
tion characteristics of these tasks, the Execution 

Task Monitor resets the dispatching priority of each 

of them to &XZMFTL and, if necessary, changes their 
order on the TCB ready chain. The specification for 
&XZMFTL must be one or two hexadecimal characters 
ranging from 00 to FF. 


Default: &XZMFTL=00 


Notes: 

1. If &XZMFTH is specified as 00, &XZMFTL is not 
used and Execution Task Monitor support for MFT 
is excluded from the generated HASP system. 
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&XZPRTY 


Explanation: Variable symbol &XZPRTY specifies a 
priority value used by the HASP Execution Task Monitor 
for MVT systems. The Execution Task Monitor periodi- 
cally analyzes each MVT HASP-controlled job step task, 
without subtasks, whose dispatching priority is 
&XZPRTY*16+11. In order to balance the CPU utiliza- 
tion characteristics of these tasks, the Execution 
Task Monitor may re-order these tasks on the TCB 

ready chain. The specification for &XZPRTY must be 

an integer between 0 and 15 inclusive, or the expres- 


sion "0-1". The latter value should be used when the 
Execution Task Monitor is to operate for MFT but not 
for MVT. 


Default: &XZPRTY=7 


Notes: 

sz If &MONINTV=0, the value of &XZPRTY is not used. 

2% If &XZPRTY is specified as 0-1 and &XZMFTH is 
specified as 0, then &MONINTV must be set to 0. 
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S$x 


$$x 


Explanation: Ordinary symbol $$x specifies the 
destination for an output data set designated in the 
user's JCL as SYSOUT=x. The specification for each 
of these ordinary symbols must be one of the charac- 
ters A, B, l, 2, or *. 


For $$x=A, associated SYSOUT data sets will be 
printed with the user's job. © 


For S$$x=B, associated SYSOUT data sets will be 
punched with the user's job. 


For $$x=l1, associated SYSOUT data sets will be 

added to the HASP special forms queue, to be printed 
with other SYSOUT data sets requiring the same 
forms. | 


For $S$x=2, associated SYSOUT data sets will be 


added to the HASP special forms queue, to be punched 
with other SYSOUT data sets requiring the same 
forms. | _ 


For $$x=*, associated SYSOUT data sets will be 
processed entirely by OS. In this case, HASP will 
add the specification UNIT=SYSDA to the JCL, unless 
the user has himself specified UNIT=information. 


Default: $SA=A SSS=A 
— -SSB=B SST=A 
SSC=A SSU=A 

sede SS$V=A 

one SSW=A 
ae? SSX=A_ 

eae s SS$Y=A 

°SH=A S$Z=A 
_SSI=A . $$1=A 

Be C$$daleee S$ 2=A 
MS $$KR2-°"" $$3=A 
| «SSLSA SS4=A 

> eM=A SS5=A 

ene SS6=A 

7eO=A SS7=A 

eae $$8=A 

SSQ=A SSO=A 

SSR=A SSO=A 
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Notes: 


ee 


For any output class x, regardless of the value 
specified for $$x, a four-digit special forms 
number can be coded as the third positional 
parameter of the SYSOUT=keyword. The specifi- 
cation is converted to a packed number (unless 
SSx=*); that is, forms number 0001 is the same 
as forms number 0l. : 

For an output class x for which $$x=*, the 
SYSOUT=parameter may be coded as described in 
the OS Job Control Language Reference manual. 

A user SYSOUT specification which includes the 
second positional parameter (program name) will 
be processed entirely by OS, regardless of 
whether the associated $$ parameter was specified 
as *, 

If a given output class x is one of the classes 
assigned to &WTRCLAS, it must not be used ina 
SYSOUT specification to be processed by OS 
(caused if S$x=*, or if the second parameter 

of SYSOUT is used), unless that class x is 
subject to requeueing as described under the 
parameter &WCLSREQ. 
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HAS P 
es RMTGEN PARAMETERS FOR SYSTEM/360 MODEL 20 STR 


This section describes the parameters used in assembly 
of the System/360 Model 20 STR Remote Terminal Program 
for HASP Remote Job Entry. The parameters are used 
during RMTGEN to specify hardware configuration and 
software options. | 


For each parameter there is an explanation, the default 
value, and frequently notes which expand upon the 
explanation. 


The parameters are listed in alphabetical order. 
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HAS P 


&CCT 


&CCT 


Explanation: Variable symbol &CCT specifies the 
degree of text compression to be provided in the 
program. For text transmission to HASP, the program 
will compress strings of &CCT or more identical 
Characters. The specification must be an integer 
between 3 and 80 inclusive. 


Default: ¢&CCT=4 


Notes: 

iy Low values of &CCT cause creation of highly 
compact records, increasing effective line speed 
at the expense of CPU 
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HAS P | &CORESIZ 
&CORESIZ 


Explanation: Variable symbol &CORESIZ specifies the 
amount of main storage available to the program in 
K bytes. The specification must be an integer greater 


Default: &CORESIZ=8. 
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HAS P 


& NUMBUFS 


&NUMBUFS 


Explanation: Variable symbol &NUMBUFS specifies the 
maximum number of buffers to be used by the program. 
The specification must be an integer greater than or 
equal to 2. 


Default: &NUMBUFS=10 


Notes: | 
L. The length of each buffer is given by HASPGEN 
parameter &TPBFSIZ. 
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HAS P 


& PUNCH 


&PUNCH 


Explanation: Variable symbol &PUNCH specifies inclu- 
Sion (&PUNCH=1) or exclusion (&PUNCH=0) of support 

for a card punch attached to the Model 20. The speci- 
fication must be either 0 or l. 


Default: &PUNCH=1 


Notes: 
IT. The program supports 1442, 2520, and 2560 card 
punches interchangeably. 
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HAS P 
7.30, RMTGEN PARAMETERS FOR SYSTEM/360 MODEL 20 BSC 


This section describes the parameters used in assembly 
of the System/360 Model 20 BSC Remote Terminal Program 
for HASP MULTI-LEAVING Remote Job Entry. The parameters 
are used during RMTGEN to specify hardware configuration 
and software options. | 


For each parameter there is an explanation, the default 
value, and frequently notes which expand upon the 
explanation. | 


The parameters are listed in alphabetical order. 
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HAS P 


&CCT 


&CCT 


Explanation: Variable symbol &CCT specifies for all 
text compression but trailing blank compression the 
minimum number of characters to be compressed. A 
duplicate character string of fewer than &CCT charac- 
ters will be treated as a string of non-duplicate 
characters for compression purposes. The specification 
must be an integer between 3 and 31, inclusive. 


Default: «sccT=4 


Notes: 

Ls See also &CMPTYPE. The value of &CCT is not 
used if &CMPTYPE=1. | 

2. A smaller value of &CCT increases efficiency 
of communication line usage at the expense of 
compute time required for compression. 
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HAS P 


&CMPTYPE 


&CMPTYPE 


Explanation: Variable symbol &CMPTYPE specifies the 
type of compression to be applied to all text trans- 
mitted from the Model 20 to the central computer. 

The specification must be either 1, 2, or 3. The 
value 1 specifies trailing blank compression; 2 speci- 
fies compression of leading, embedded, and trailing 
blanks, and 3 specifies compression of all duplicate 
character strings. 


Default: &CMPTYPE=2 


Notes: 
ne See also &CCT. 
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HAS P 


&CORESIZ 


&CORESIZ 


Explanation: Variable symbol &CORESIZ specifies the 
size of Model 20 main storage in Kbytes (1 Kbyte = 
1024 bytes). The specification must be an integer 
between 8 and 32 inclusive. 


Default: &CORESIZ=8 
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Sh) et 


HAS P &ERRMSGN - 
& ERRMSGN 


Explanation: Variable symbol &ERRMSGN specifies the 
number of four-byte entries to be assembled in the 
System/360 Remote Terminal as an error message log 
table. The specification must be an integer not less 
than 8. } 


Default: &ERRMSGN=8 
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HAS P | — &LINESPD 


& LINESPD 


Explanation: Variable symbol &LINESPD specifies the 
Speed, in baud, of the communication line to be used 
between the Model 20 and the central computer. The 
specification must be a positive integer. 


Default: &LINESPD=2000 
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HAS P 


&NUMBUFS 


&NUMBUFS 


Explanation: Variable symbol &NUMBUFS specifies number 
of teleprocessing buffers to be constructed by the 
Model 20 Remote Terminal program. The specification 
must be an integer no less than given by the formula 
2*X+1 

where 

X=1 if either a 2520 or a 2560 is to be used as 

both a reader and a punch, or 
0 otherwise. 


Default: &NUMBUFS=8 


Notes: 

i The length of each buffer is &MLBFSIZ+5 bytes 
(rounded up to. the next full word); the value 
of HASPGEN parameter &MLBFSIZ is automatically 
propagated to RMTGEN. 

2% If &NUMBUFS specifies more buffers than can be 
built in available storage, the Remote Terminal 
program will build as many buffers as it can. 

Se It is recommended that at least two buffers be 
furnished for each output device and for the 
communication adapter. 
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HAS P 


S&SNUMTANK 


&NUMTANK 


Explanation: Variable symbol &NUMTANK specifies the 
number of decompression buffers ("decompression tanks") 
to be assembled in the Model 20 Remote Terminal program. 
The specification should be an integer not less than 2. 


Default: &NUMTANK=8 


Notes: 

i The length of each decompression tank is &PRTSIZE+6. 

2. It is recommended that at least two tanks each be 
provided for the printer and the punch. 

34 For an 8K Model 20, specification of &NUMTANK 
greater than 8 may cause the Remote Terminal 
program to assemble larger than X'1F00' bytes 


(8K-256); the resultant program will fail to 
load. 
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HAS P 


&PDEV (1) 


&PDEV(1) 


Explanation: Subscripted variable symbol &PDEV (1) 
specifies device type for the Model 20 printer. The 
specification must be either 1403 or 2203. 


Default: &PDEV(1)=2203 
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HAS P 


&PRTCONS 


&PRTCONS 


Explanation: Variable symbol &PRTCONS specifies degree 
of use of the printer as an output console. The speci- 
fication must be either 0, 1, or 2. 


For &PRTCONS=0, the printer will never be used as an 
output console. 


For &PRTCONS=1, the printer will be used as an output 
console. If the Model 20 receives an operator message 
while the printer is printing a job, the message will 

be held in a decompression tank. If all but two of the 
decompression tanks contain messages, the job's printing 
will be stopped, a page ejected, the messages printed, 
another page will be ejected, and the job will resume 
printing. 


For &PRTCONS=2, the printer will be used as an output 
console only if it is not printing a job. Otherwise, 
operator messages received from the central computer 

will be thrown away. 


Default: &PRTCONS=0 


Notes: 

da If sWDEV(1) is not specified as zero, &PRTCONS is 
not used and the printer will never be used as an 
output console. | 

2% If &PRTCONS=1 or &PRTCONS=2, console support must 
be indicated for this Remote Terminal at HASPGEN 
time. See HASPGEN parameter RMTnn. 
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HAS P 


&PRTSIZE 


— &PRTSIZE 


Explanation: Variable symbol &PRTSIZE specifies the 
length in bytes of the text portion of each decompres- 
sion tank. Each tank must be long enough to hold a 
maximum-length output record to either the printer, 

the punch, or the operator console. The specification 
must be an integer that is the largest of 80 (if S&UDEV(1) 


is not zero), 120 (if &WDEV(1) is not zero), and the 


line width of the printer. 


Default: &PRTSIZE=120 
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HAS P 


&RADR (1) 


&RADR(1) 


Explanation: Subscripted variable symbol &RADR(1l) 
specifies the unit address of the Model 20 card 
reader. The specification must correspond to the 
specification for &RDEV(l) as follows: 


& RDEV (1) & RADR (1) 
2501 1 
2520 2 
2560 2 


Default: &RADR(1)=1 
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ar 
ook 


HAS P 


& RDEV (1) 


&RDEV(1) 


Explanation: Subscripted variable symbol &RDEV(1) 
specifies device type for the Model 20 card reader. 


The specification must be either 2501, 2520, or 2560. 


Default: & RDEV (1) =2501 


Notes: 
1. See also &RADR(1) 
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HAS P &SUBMOD 


& SUBMOD 


Explanation: Variable symbol &SUBMOD specifies the 
Submodel number of the System/360 Model 20 for the 
specified Remote Terminal. The specification must 
be a valid System/360 Model 20 Submodel number. 


Default: &SUBMOD=2 
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HAS P 


&UADR (1) 


&UADR(1) 


Explanation: Subscripted variable symbol &UADR(1) 
specifies the unit address of the Model 20 card punch. 
The specification must correspond to the specification 
for &UDEV(1) as follows: , 


&UDEV (1) & UADR (1) 
1442 | 3 
2520 2 
2560 2 

0 not used 


Default: &UADR(1)=3 
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HAS P 


&UDEV (1) 


&UDEV(1) 


Explanation: Subscripted variable symbol &UDEV (1) 
Specifies device type for the Model 20 card punch. 
The specification must be either 1442, 2520, 2560, 
or 0. Specification 0 is used when the Model 20 
does not include a card punch. 


Default: &UDEV(1)=1442 


Notes: 
od. See also &UADR(1), unless sUDEV(1)=0. 
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HAS P 


&WDEV (1) 


&WDEV(1) 


Explanation: Subscripted variable symbol &WDEV (1) 
specifies device type for the Model 20 console. 

The specification must be either 2152 (if a console 
1s present) or 0 (if no console is present). 


Default: &WDEV(1)=0 


Notes: 

1. If &WDEV(1)=2152, console support must be indicated 
for this Remote Terminal at HASPGEN time. See. 
HASPGEN parameter RMTnn. 
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HAS P 


SWTOSIZE 


&WTOSIZE 


Explanation: Variable symbol sWTOSIZE specifies the 


maximum length in bytes of a HASP operator command to 
be transmitted from the Model 20 to the central com- 
puter. The specification must be a positive integer. 


Default: #&WTOSIZE=120 


Notes: 
se If s&sWDEV(1)=0, this parameter is not used. 
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HAS P 


& XPARENT 


&XPARENT 


Explanation: Variable symbol &XPARENT specifies presence 
or absence of the text transparency feature. If the 
Binary Synchronous Communication Adapters at both the 
Model 20 and the central computer have the text trans- 
parency feature, YES should be specified; otherwise NO 
should be specified. 


Default: &XPARENT=YES 


BSC-20 RMTGEN Parameters - Page 7.3.19 


445 


HAS P 
7.4 RMTGEN PARAMETERS FOR SYSTEM/360 (EXCEPT MODEL 20) BSC 


This section describes the parameters used in assembly 
of the System/360 BSC Remote Terminal Program for HASP 
MULTI-LEAVING Remote Job Entry. The parameters are 
used during RMTGEN to specify hardware configuration 
and software options. 


For each parameter there is an explanation, the default 
value, and frequently notes which expand upon the 
explanation. 


The parameters are listed in alphabetical order. 


-BSC-360 RMTGEN Parameters - Page 7.4.1 


446 


HAS P 


& ADAPT 


& ADAPT 


Explanation: Variable symbol &ADAPT specifies the 
unit address of the Binary Synchronous Communication 
Adapter to be used by the System/360 Remote Terminal 
to communicate with HASP at the central computer. 
The specification must be a valid unit address. 


Default:  &ADAPT=020 
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H AS P 


&CCT 


&CCT 


Explanation: Variable symbol &CCT specifies for all 
text compression but trailing blank compression the 
minimum number of characters to be compressed. A © 
duplicate character string of fewer than &CCT charac- 
ters will be treated as a string of non-duplicate 
characters for compression purposes. The specification 
must be an integer between 3 and 31, inclusive. 


Default: ¢&CCT=4 


Notes: | 

Ls See also &CMPTYPE. The value of &CCT is not 
used if &CMPTYPE=1. 

2. A smaller value of &CCT increases efficiency 
of communication line usage at the expense of 
compute time required for compression. 
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HAS P 


&CMPTYPE 


&CMPTYPE 


Explanation: Variable symbol &CMPTYPE specifies type 
of compression to be applied to all text transmitted 
from the System/360 Remote Terminal to the central 
computer. The specification must be either 1, 2, or 
3. The value 1 specifies trailing blank compression; 
2 specifies compression of leading, embedded, and 
trailing blanks, and 3 specifies compression of all 
duplicate character strings. 


Default: &CMPTYPE=2 


Notes: 
1. See also &CCT. 
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HAS P 


&CORESIZ 


&CORESIZ 


Explanation: Variable symbol &CORESIZ specifies the 
size of main storage for the System/360 Remote Terminal 
in Kbytes (1 Kbyte = 1024 bytes). The specification 
must be an integer between 8 and 32 inclusive. If 

the System/360 is larger than 32 Kbytes, &CORESIZ must 
be specified as 32. 


Default: &CORESIZ=32 
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HAS P &ERRMSGN 


& ERRMSGN 


Explanation: Variable symbol &ERRMSGN specifies the 
number of four-byte entries to be assembled in the 


Model 20 Remote Terminal program as an error message 


log table. The specification must be an integer not 
less than 8. 


Default: &ERRMSGN=8. 
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HAS P | &LINESPD 
& LINESPD 


Explanation: Variable symbol &LINESPD specifies the 
speed, in baud, of the communication line to be used 
between the System/360 Remote Terminal and the central 
-computer. The specification must be a positive integer. 


Default: &LINESPD=2000 
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HAS P 


&MACHINE 


&MACHINE 


Explanation: Variable symbol &MACHINE specifies the 
model number of the System/360 to be used as a HASP 
Remote Terminal. The specification must be a valid 
System/360 model number for a System/360 which includes 
the standard instruction set and the decimal instruction 
set. 


Default: &MACHINE=30 
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SNUMBURS 


&NUMBUE 


Explanation: Variable symbol &NUMBUFS specifies number 
of teleprocessing buffers to be’ constructed by the 
System/360 Remote Terminal program. The specification 
must be an integer no less than given by the formula 
2*X+1 

where 

X=] if either a 2520 or a 1442 is to be used as 

both a reader and a punch, or 
0 otherwise. 


Default: &NUMBUFS=8 


Notes: | 

i? The length of each buffer is &MLBFSIZ+5 bytes 
(rounded up to a multiple of 4); the value of 
HASPGEN parameter &MLBFSIZ is automatically 
propagated to RMTGEN, 


2 If &NUMBUFS specifies more buffers than can be 


built in available storage, the Remote Terminal 
program will build as many buffers as it can. 

ce It is recommended that at least two buffers be 
furnished for each output device and for the 
communication adapter. 
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C3 
Ce] 


HAS P 


& NUMTANK 


&NUMTANK 


Explanation: Variable symbol &NUMTANK specifies the 
Tamber of decompression buffers ("decompression tanks") 
to be assembled in the System/360 Remote Terminal 
program. The specification should be an integer not 
less than 2. 


Default: &NUMTANK=8 


Notes: 

Le The length of each decompression tank is &PRTSIZE+6, 

2 It is recommended that at least two tanks be pro- 
vided for each printer and each punch (3 for a 2540 
punch). | 
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HAS P | oat fag a | | &PADR(n) 
&PADR (n) 


EX andeione “gubscripted variable symbols &PADR(n) 
specify unit addresses for the printers defined by 
&PDEV(n). For: each &PDEV(n) not specified as zero, 
the corresponding: symbol &PADR(n) must specify the 
device's 3+character hexadecimal unit address. 





Default: ¢PADR(1)=00E 
ae &PADR(2)=00F 

&PADR (3) =FFF 

&PADR (4) =FFF 
&PADR(5)=FFF | 
&PADR (6) =FFF 

ia ail 
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HAS P 


& PDEV (n) 


&PDEV(n) 


Explanation: Subscripted variable symbols &PDEV(n) 
specify the existence and device types of the Remote 
Terminal printers. Each specification must be either 
1403, 1443, or 0. A specification of 0 indicates that 
the associated printer does not exist. 


Default: &PDEV(1)=1403 
& PDEV (2) =0 
&PDEV (3) =0 
&PDEV (4) =0 
&PDEV (5) =0 
&PDEV (6) =0 
&PDEV (7) =0 


Notes: 

1. If &PDEV(n) is specified as a device type, then 
&UDEV(8-n) must be specified as zero. 

2 If &PDEV(n+l) is specified as a device type, then 
&PDEV(n) must be specified as a device type. 

3% If more than one printer is specified, a Device 
Control Table (DCT) for each additional printer 
must be added to the HASP System. 
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HAS P 


&PRTSIZE 


&PRTSIZE — 


Explanation: Variable symbol &PRTSIZE specifies the 
length in bytes of the text portion of each decompres- 
Sion tank. Each tank must be long enough to hold a 
maximum-length output record to either a printer, a 
punch, or the operator console. The specification 
must be an integer that is the larger of 120 and the 
line width of the widest printer. 


Default: &PRTSIZE=132 
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HAS P | &RADR(n) 


& RADR (n) 


Explanation: Subscripted variable symbols &RADR(n) 
specify unit addresses for the readers defined by 
&RDEV(n). For each &RDEV(n) not specified as zero, 
the corresponding symbol &RADR(n) must specify the 
device's 3-character hexadecimal unit address. 


Default: &RADR(1)=00C 
&RADR (2) =FFF 
&RADR (3) =FFF 
&RADR (4) =FFF 
&RADR (5) =FFF 
&RADR (6) =FFF 
& RADR (7) =FFF 
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HAS P 


& RDEV (n) 


&RDEV(n) 


Explanation: Subscripted variable symbols &RDEV(n) 
specify the existence and device types of the Remote 
Terminal readers. Each specification must be either 
2540, 2501, 2520, 1442, or 0. A specification of 0 
indicates that the associated reader does not exist. 


Default: &RDEV(1)=2540 
& RDEV (2) =0 
& RDEV (3) =0 
&RDEV (4) =0 
&RDEV (5) =0 
&RDEV (6) =0 
&RDEV (7) =0 


Notes: 

Te If &RDEV (n+l) is specified as a device type, then 
&RDEV(n) must be specified as a device type. 

2% If more than one reader is specified, a Device 
Control Table (DCT) for each additional reader 
must be added to the HASP System. 
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HAS P &UADR(n) 


& UADR (n) 


Explanation: Subscripted variable symbols &UADR(n) 
specify unit addresses for the punches defined by 
&UDEV(n). For each &UDEV(n) not specified as zero, 
the corresponding symbol s&UADR(n) must specify the 
device's 3-character hexadecimal unit address. 


Default: &UADR(1)=00D 
&UADR (2) =FFF 
&UADR (3) =FFF 
&UARD (4) =FFF 
&UARD (5) =FFF 
&UARD (6) =FFF 
&UARD (7) =FFF 
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HAS P &UDEV(n) 


&SUDEV (n) 


Explanation: Subscripted variable symbols &UDEV (n) 
specify the existence and device types of the Remote 
Terminal punches. Each specification must be either 
2540, 2520, 1442, or 0. A specification of 0 indicates 
that the associated punch does not exist. 


Default: SsUDEV(1)=2540 
&UDEV (2) =0 
&UDEV (3) =0 
&UDEV (4) =0 
&UDEV (5) =0 
&UDEV (6) =0 
&UDEV (7) =0 - 


Notes: 

i If &UDEV(n) is specified as a device type, then 
&PDEV(8-n) must be specified as zero. 

24 If &sUDEV(n+1) is specified as a device type, then 
&UDEV(n) must be specified as a device type. 

33 If more than one punch is specified, a.Device 
Control Table (DCT) for each additional punch must 
be added to the HASP System. 
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H AS P 


&WADR (1) 


&WADR(1) 


Explanation: Subscripted variable symbol &WADR(1) specifies 
the unit address of the 1052 operator console on the 
System/360 Remote Terminal. The specification must 

be a 3-character hexadecimal unit address. 


Default: &WADR(1)=01F 
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HAS P 


 &WTOSIZE 


&WTOSIZE 


Explanation: Variable symbol &WTOSIZE specifies the 
maximum length in bytes of a HASP operator command to 
be transmitted from the System/360 Remote Terminal 

to the central computer. The specification must be 

a positive integer. 


Default: &WTOSIZE=120 
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HAS P 


&XPARENT 


&XPARENT 


Explanation: Variable symbol &XPARENT specifies 
presence or absence of the text transparency feature. 
If the Binary Synchronous Communication Adapters at 
both the System/360 Remote Terminal and the central 
computer have the text transparency feature, YES 
should be specified; otherwise NO should be specified. 


Default: &XPARENT=YES 
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HAS P 
7.5 RMTGEN PARAMETERS FOR 1130 


This section describes the parameters used in assembly 
of the 1130 Remote Terminal Program for HASP MULTI- 
LEAVING Remote Job Entry. The parameters are used 
during RMTGEN to specify hardware configuration and 
software options. 


For each parameter there is an explanation, the default 
value, and frequently notes which expand upon the 
explanation. 


The parameters are listed in alphabetical order. 
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Hi AS P 


&C LOCK 


&CLOCK 


Explanation: The variable symbol &CLOCK is used to 
Specify the type of communication adapter clocking 
available on the 1130 to be used by the workstation 
program. The specification of &CLOCK=0 is interpreted 
to mean that data set clocking is being used. The 
value &CLOCK=1 specifies internal (1130) clocking. 


Default: &CLOCK=0 


Notes: | 

Ls The rate of insertion of the synchronous idle 
sequence in the transmitted data is determined 
by the variables &CLOCK, &LINESPD and &TRANPRN. 
The relationship of these variables to the inser- 
tion rate is; 


& CLOCK & TRANPRN INSERTION EVERY: 
0 0 &LINESPD/8 characters 
0 1 &LINESPD/8 characters 
1 0 70 characters 
1] 1 &LINESPD/8 characters 


2% The equation used for the insertion rate is: 
(SLINESPD/8) *T 
where T is 1.00 second which is the nominal 2701 
timer value. 
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&CMPTYPE 











&CMPTYPE 


Explanation: The variable symbol &CMPTYPE is used to 
Specify the compression technique that is to be applied 
to the data transmitted to the central HASP system. 

The choices for &CMPTYPE are: 


&CMPTYPE=0 for no compression of duplicate char- 
| acters or truncation of trailing blanks. 


&CMPTYPE=1 for trailing blank truncation only. 
&CMPTYPE=2 for full compression: trailing blank 


truncation and encoding of duplicate 
characters. 


Default: &CMPTYPE=2 


Notes: 


Le 


The process of compressing input data offers optimum 
performance with respect to efficient line utiliza- 
tion. However, the factors of line speed, CPU 
availability, buffer size, line turn-around time, 
nature of the data to be compressed, etc., are 
variables which contribute to the overall operation 
of the workstation program. Since compression and 
truncation require considerable CPU time, the user 
may decide, on the basis of the other variables, 

to respecify the compression technique. 
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HAS P 


& DELAY 


& DELAY 


Explanation: The variable symbol &DELAY is used to 
define the number of intervals of time that RTP1130 


will delay in transmitting a "handshaking" sequence 


(DLE-ACKO) to the central HASP site. The hardware 
program timer clock is used to measure the delay and 
is assumed to be set to a nominal value of .35 seconds. 


Default: &DELAY=3 
eet 


Notes: | 

Ls &DELAY=3 results in a delay of 1.05 seconds, 
assuming a timer interval of .35 seconds. 

Zs The purpose of the delay when "handshaking" is 

| to minimize CPU processing at the central HASP 
computer when no data is being transmitted. 

3. The value of &DELAY must not be set to such a 
large increment that the delay will be greater 
than the timeout period of the central site 
2701/2703. 
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HAS P 


| &FULLIST 








&FULLIST 


Explanation: The variable symbol &FULLIST is used 

to specify the type of assembly listing which is pro- 
duced by the 0S/360 assembler during the RMTGEN process. 
If the value of &FULLIST is set to 0, then the assembly 
listing produced will be according to the PRINT NOGEN 
Stipulation of the assembler. If the value of &FULLIST 
is set to l, the listing will be produced according to 
the PRINT GEN stipulation. 


Default: &FULLIST=1 


Notes: 

1. Since most of the code in RTP1130 and RTPLOAD 
is created by Macro instructions, the specifica- 
tion of &FULLIST=0 will essentially produce a 
source listing (cross referenced) without the 
1130 assembled instructions. Error messages 
will not appear on the listing. 
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HAS P 


& LINESPD 


&LINESPD 


Explanation: The variable symbol &LINESPD is used 

to specify the baud rate for the communication line 
interface to the workstation program. The value should 
correspond to the selected setting of the baud rate 
Switch on the 1130 SCA control panel: 1200,2000,...,etc. 


Default: &LINESPD=2000 


Notes: 


ss The rate of insertion of the synchronous idle 


sequence (DLE-SYN or SYN-SYN) in the transmitted 
data is determined by the variables &CLOCK, 
&LINESPD and &TRANPRN. See note l of &CLOCK 
description. 
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HAS P | | &MACHSIZ 
&MACHSIZ 


Explanation: Variable symbol &MACHSIZ specifies the 
amount of 1130 core to be used by RTP1130. The value 
Of &MACHSIZ is in units of 1130 words. 


Default: &MACHSIZ=8192 


Notes: 

Le The value of &MACHSIZ is interpreted to mean that 
"SMACHSIZ" number of words, starting at location 
0, are available for the workstation program con- 
Sisting of RTPBOOT, RTPLOAD and RTP1130. 


2% The same variable symbol must be defined for 
RTPLOAD and should have the same value. 
She The value of &MACHSIZ may be less than the actual 


available storage but must not be greater. 
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HAS P 


&PN1442 


&PN1442 


Explanation: The variable symbol &PN1442 is used to 
define a 1442 punch. If the variable is set to l, 
then RTP1130 will include support for punched card 
output produced by jobs at the Central HASP site. 

If the variable is set to 0, no support for the 1442 
punch will be provided. See &RD1442 for the defini- 
tion of a reader function on the 1442. 


Default: &PN1442=1 
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A. SP 


& PRFOTLW 














&PRFOTLW 


Explanation: The value of the variable symbol &PRFOTLW 
1s used to define the line width of the 1403 printer 
Specified by &PR1403. The choices are 120 or 132 
character lines. | 7 


Default: &PRFOTLW=120 


Notes: 

Ls The definition of the line width for all printers 
on a particular remote is a HASPGEN requirement. 
see HASPGEN parameter RMTnn. 
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H AS P 


&PR1132 


&PR1132 


Explanation: The variable symbol &PR1132 is used to 
define an 1132 printer. If the variable is set to 
1, then RTP1130 will include support for the 1132 to 
print job output. If the variable is set to 0, no 
support will be included in RTP1130 for the 1132. 


Default: &PR1132=0 
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H A S P 


&PR1403 


&PR1403 


Explanation: The variable symbol &PR1403 is used to 
define a 1403 printer for use as an output device. 
If the value of &PR1403 is 1, then the 1403 function 


| will be included in RTP1130. If the value is 0, the 


function is deleted from RTP1130.. 
Default: &PR1403=1 


Notes: 





od. See &PRFOTLW for specifying the line width of © 


the 1403. 
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&RDL442 


&RD1442 


Explanation: The variable symbol &RD1442 is used to 
define a 1442 as a card reader. If the variable is 
set to 1, then RTP1130 will be assembled with all 
necessary control blocks and support routines to pro- 
vide job input from the 1442. If the variable is set 
to 0, no support for the 1442 reader will be provided 
in RTP1130. See &PN1442 for a definition of the 
punch function on the 1442. 


Default: &RD1442=1 


Notes: 

1. If the variable &RD1442 is set to 1 anda 1442 
reader does not exist then the operation of the 
workstation program may be unpredictable. 
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“HAS P 


&RD2501 








Explanation: The variable symbol &RD2501 is used to 
define a 2501 card reader. If the variable is set 

to 1, then RTP1130 will be assembled with all necessary 
control block and subroutines to support the 2501 as 

a job input device. If the variable is set to 0, 

no support for the 2501 will be included in RTP1130. 


Default: &RD2501=0 


Notes: 
1. If the variable &RD2501 is set to 1 and a 2501 
does not exist then the operation of the work- 


station program will be unpredictable and usually 
unproductive. 
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I &RD25ON 


HAS P 


&RTPLORG 


&RTPLORG 


Explanation: The variable symbol &RTPLORG defines 
the origin in 1130 storage of the program loader 
RTPLOAD which is used to load RTP1130. 


Default: é&RTPLORG=2* (&MACHSIZ-1024) 


Notes: 

Ls The value of the above expression, assuming 
&MACHSIZ=8192, is 14336 (which is twice the 
actual 1130 storage address because the value 
is used in an ORG operation and must be in terms 
of bytes not 1130 words. 

2 The RTPLOAD program must origin in the storage 
available between the end of RTP1130 (beginning 
of buffer pool) and the end of defined (&MACHSIZ) 
storage MINUS the length of RTPLOAD. The default 
value of &RTPLORG allows for an RTPLOAD of 1024 
words in size. 
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HAS P 


&TRANPRN 


Explanation: The variable symbol &TRANPRN is used to 
define the simulation of the Binary Synchronous | 
Transparency feature. If the value of &TRANPRN is set 
to 1, then RTP1130 will simulate the transparency 
feature in the same manner as the 2701 SDA-II adapter 
equipped with the transparency feature. If the 
variable is set to 0, no simulation will occur and 
therefore data which contains transparent characters 


cannot be properly processed by RTP1130. 


Default: &TRANPRN=1 


Notes: 

Ly If &TRANPRN=0 is specified, the conversion of 
card code data is monitored and all BSC control 
characters are converted to hexadecimal 0. This 
prevents mispunched data from causing an infinite 
error retry if the central site does not have 

transparency. 

2. See &LINESPD and & CLOCK for additional inetoenes 
of &TRANPRN. 

3 If &TRANPRN=1, the generated Remote Terminal 
program will communicate only with a 2701 or 2703 
adapter which has the text transparency feature. 
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 &TRANPRN 


HAS P 


7.6 


RMTGEN PARAMETERS FOR 1130 LOADER 


This section describes the parameters used in assembly of 
RTPLOAD, the 1130 Loader Program. RTPLOAD is used to load 
the 1130 Remote Terminal Program. RTPLOAD's three parameters 
specify machine size, loader origin, and an assembler list 
option. 


For each parameter there is an explanation, the default value, 
and frequently notes which expand upon the explanation. 


The RMTGEN processes produce the object decks for RTPLOAD 
and RTP1130. The bootstrap loader (RTPBOOT) cannot be pro- 
duced on a System 360 and must be punched by keypunch as 
indicated in Section 4.14.3. 


The parameters are listed in alphabetical order. 
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&FULLIST 








Explanation: The variable symbol &FULLIST is used 

to specify the type of assembly listing which is pro- 
duced by the OS/360 assembler during the RMTGEN process. 
If the value of &FULLIST is set to 0, then the assembly 
listing produced will be according to the PRINT NOGEN 
stipulation of the assembler. If the value of &FULLIST 
is set to l, the listing will be produced according to 
the PRINT GEN stipulation. 


Default: &FULLIST=1 


Notes: 

ils Since most of the code in RTP1130 and RTPLOAD 
is created by Macro instructions, the specifica- 
tion of &FULLIST=0 will essentially produce a 
source listing (cross referenced) without the 
1130 assembled instructions. Error messages 
will not appear on the listing. 
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&FULLIST © 


ep i &MACHSIZ 


&MACHSTIZ 


Explanation: Variable symbol &MACHSIZ specifies the 
amount of 1130 core to be used by RTPLOAD. The value 
of &MACHSIZ is in units of 1130 words. 


Default: &MACHSIZ=8192 


Notes: 

1 The value of &MACHSIZ is interpreted to mean that 
“S&MACHSIZ" number of words, starting at location 
0, are available for the workstation program con- . 
Sisting of RTPBOOT, RTPLOAD and RTP1130. 


2 The same variable symbol must be defined for 
RTP1130 and should have the same value. 
3% The value of &MACHSIZ may be less than the actual 


available storage but must not be greater. 
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& RTPLORG 





Explanation: The variable symbol &RTPLORG defines 
the origin in 1130 storage of the pEogren loader 
RTPLOAD which is used to load RTP1130. 


Default: &RTPLORG=2* (&MACHSIZ-1024) 


Notes: 


ai 


' The value of the above expression, assuming 


&MACHSIZ=8192, is 14336 (which is twice the 
actual 1130 storage address because the value 

is used in an ORG operation and must be in terms. 
of bytes not 1130 words. 

The RTPLOAD program must origin in the storage 
available between the end of RTP1130 (beginning 
of buffer pool) and the end of defined (&MACHSIZ) 
storage MINUS the length of RTPLOAD. The default 
value of &RTPLORG allows for an RTPLOAD of 1024 
words in size. 
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&RTPLORG 


HAS P 
Vcd RMTGEN PARAMETERS FOR SYSTEM/3 


This section describes the parameters used in assembly 
of the System/3 Remote Terminal Program for HASP MULTI- 
LEAVING Remote Job Entry. The parameters are used 
during RMTGEN to specify hardware configuration and 
software options. 


For each parameter there is an explanation, the default 
value, and frequently notes which expand upon the 
explanation. 


The parameters are listed in alphabetical order. 
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HAS P 


& COMP 











&COMP 


Explanation: Variable symbol &COMP specifies degree 
of text compression to be provided for all text trans- 


mitted from the System/3 to HASP. The specification 


must be either 0, 1, or 2. 


For &COMP=0, neither compression nor truncation is 


performed. 


For &COMP=1, trailing blanks are truncated from each 


logical record before it is transmitted. 


For &COMP=2, compression takes place after truncation. 
Strings of from two to 31 blanks are compressed to a 
Single byte; strings of from three to 31 duplicate 
characters are compressed to two bytes. | 


Default: &COMP=2 
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HAS P 


& DEBUG 


&DEBUG 


Explanation: Variable symbol &DEBUG specifies inclusion 
Or exclusion of certain validity tests and a core dump 
program in the System/3 Remote Terminal Program. The 
specification must be either 0 or l. 


Default: &DEBUG=0 
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HASP | 


&DIAL, 











&DIALI 


Explanation: Variable symbols &DIAL and &DIAL1 specify 
the telephone number to be used during the initializa- 
tion process. The values will be included on the 
default /*SIGNON card assembled into the System/3 
Remote Terminal Program and preceded by the keyword 
DIAL (unless the parameters are left at their defaults). 
Each specification is a string of from one to eight 
decimal digits. If the telephone number is eight or 
fewer digits long, it should be specified by é&DIAL. 

If the telephone number is longer than eight digits, 
its leftmost eight digits should be specified by &DIAL 
and the remaining oegter by &DIALI1. 


Default: &DIAL=[null string] 


&DIALI=[{null string] 
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Cs ———— sca oo ~~ &D ; A { iii ae 


HAS P 


&MACHSIZ 


&MACHSIZ 


Explanation: Variable symbol &MACHSI2Z specifies the 
Size of System/3 Core storage. The specification 
should be either 8192, 12288, 16384, 24576, or 32768 
for core storage sizes of 8K, 12K, 16K, 24K or 32K 
respectively. 


Default: &MACHSIZ=8192 
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HAS P 


&PASSWD 








&PASSWD 


Explanation: Variable symbol &PASSWD specifies a 

password to be used during the SIGNON process. The 
value will be included on the default /*SIGNON card 
assembled into the System/3 Remote Terminal Program. 


The specification must be a character string of from 


one to eight characters. If blanks are desired, no 
specification may be made. | 


Default: &PASSWD=[null string] 
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H AS P 


&PC (n) 


&PC(n) 


Explanation: Subscripted variable symbols &PC(n) 
specify skip information for the 5203 printer. The 
value to which &PC(n) is set will be the print line 
number to which paper will be skipped when the System/3 
Remote Terminal Program simulates the 1403 command 
"Skip to Channel n". Each specification must be an 
integer between 0 and &S3FORML, inclusive. A specifi- 
cation of 0 causes no forms movement. 


Default: é&PC(l)=1l 


&PC (2)=0 
&PC (3) =0 
&PC (4) =0 
&PC (5) =0 
&PC (6) =0 
&PC (7) =0 
&PC (8) =0 
&PC (9)=0 
&PC (10) =0 
&PC (11)=0 
&PC (12)=&S3FORML-5 
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HAS P 


&PRTCONS 





&PRTCONS 


Explanation: Variable symbol &PRTCONS specifies utili- 
zation of the 5203 printer as an operator's output 
console. The specification must be 0, l, or 2. 


For &PRTCONS=0, the 5203 printer will never be used as 


an operator's output console. 


For &PRTCONS=1, the System/3 Remote Terminal Program 
will attempt to hold operator messages from HASP until 
a job has completed printing. However, if two or more 
MULTI-LEAVING buffers are received containing HASP 
operator messages, the 5203 will eject a page (skip to 
channel 1), print the HASP operator messages, eject 
another page, and resume printing its job. 


For &PRTCONS=2, the System/3 Remote Terminal Program 
will throw away all operator messages while the 5203 


is printing a job. While the 5203 is dormant , it 
will print any received messages. 


Default: &PRTCONS=2 


Notes: 
is If &$35471= 1, the value of &PRTCONS is ignored 
and assumed to be zero. 
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HAS P &S3FORML 
&S 3FORML 


Explanation: Variable symbol &S3FORML specifies the 
number of print lines on a page of the continuous 
forms which will be used in the 5203 printer. The 
specification must be an integer not less than 6. 


Default: &S3FORML=66 
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HASP | - &S3NPUNS 
&S3NPUNS 


Explanation: Variable symbol &S3NPUNS specifies the — 
maximum number of jobs that can be punching simultaneously 
at the System/3 Remote erminal. The specification must 
be 1, 2, or 3. (A value of 3 allows simultaneous opera- 
tion of both 5424 hoppers and the 1442 hopper as punches.) > 


Default: &S3NPUNS=1 


Notes: | 

Le If &S3NPUNS is set to 2 or 3, extra device control 
tables must be added for the appropriate remote to 
the HASP System at HASPGEN time. 
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H AS P 


&S 3NRDRS 


&S3NRDRS 


Explanation: Variable symbol &S3NRDRS specifies the 
maximum number of job streams that can be reading 
Simultaneously from the System/3 Remote Terminal. 
The specification must be l, 2, or 3. (A value of 

3 allows simultaneous operation of both 5424 hoppers 
and the 1442 hopper as readers.) 


Default: &S 3NRDRS=1 


Notes: 


i If &S3NRDRS is set to 2 or 3, extra device control 


tables must be added for the appropriate remote to 
the HASP System at HASPGEN time. 
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HAS P 


&S 30BJ DK 











a | -&S30BJDK 


Explanation: Variable symbol &S30BJDK specifies inclu- 
Sion of a facility to punch Operating System object 
decks. Text transparency should be present. The 
Specification should be 0 or l. | 


If &S30BJDK=1, each card of an OS object deck will be 
expanded and punched into two 96-column cards. These 
cards will be recognized when later read by a System/3 
Remote Terminal program for which &S3OBJDK=1, and for 
each two 96-column cards read an OS object deck card 
image will be transmitted. | 


Default: &S30BJDK=0 
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HAS P 


&S3SIP 


&S3S1P 


Explanation: Variable symbol &S3SIP specifies usage 

of those bytes of System/3 core storage between X'100' 
and X'1FF', inclusive. The specification must be either 
O0.or 1. For &S3SIP=1, the System/3 Remote Terminal 
Program will not use the bytes; their values will be 
preserved for the use of the System/3 Card System 
Initialization Program. 


Default: &S 3SIP=0 
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HAS P &S3TRACE 


&S 3TRACE 


Explanation: Variable symbol &S3TRACE specifies the 
number of four-byte entries in the System/3 Remote 
Terminal Program's internal error message table. The 
specification must be an integer greater than l. 


Default: &S 3TRACE=10 
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HAS P &S3XPAR 
&S3XPAR 


Explanation: Variable symbol &S3XPAR specifies presence 
or absence of the EBCDIC text transparency feature. The 
specification should be 1 if both the central computer's 
communications adapter and the System/3 BSCA have the 
EBCDIC text transparency feature; otherwise the specifi- 
cation should be 0. 


Default: &S3XPAR=0 
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| &S31442 
HAS P 


&S31442 


Explanation: Variable symbol &S31442 specifies inclu- 
Sion or exclusion of support for the 1442 Card Reader- 
Punch (RPQ). The specification must be 1 for inclusion 
and 0 for exclusion of 1442 support. 


Default: 6&S31442=0 


Notes: 


eee ia 


Le If &6S$31442=1, the resultant System/3 Remote Termi- 
nal Program requires that a 1442 be present on. 
the System/3. 
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HAS P| 7 &S35471 


&S 35471 


Explanation: Variable symbol &&35471 specifies 
presence or absence of a 5471 Printer-Keyboard on 

the System/3. The 5471 will be used as an operator's 
input/output console. The specification must be l 

if a 5471 is present; otherwise it must be 0. 


Default: &S$35471=0 
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HA SP 


&S 35475 


&S35475 


Explanation: Variable symbol &S35475 specifies presence 
or absence of a 5475 Data Entry Keyboard on the System/3. 
The 5475 will be used as an operator's input console. 
The specification must S 1 if a 5475 is present; other- 
wise it must be 0. 


Default: &S35475=0 


Notes: 
Le If &S35471l=1, this parameter is ignored. 
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BoA S |P 


&S 396COL 


&S396COL 


Explanation: Variable symbol &S396COL specifies inclu- 
Sion or exclusion of the System/3 load-mode punch option. 
The specification must be either 0 or l. If &S396COL 

is specified, the resultant System/3 Remote Terminal 
Program will be capable of receiving correctly the 
punched output of a System/3 RMTGEN. 


Default: &S396COL=0 
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8.0 HASP CONTROL TABLE FORMATS 





This sections contains block diagrams which depict the formats 
of the HASP Control Tables which are not described in other 
sections of this manual. 
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Hi A S P 


Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT 


Displacement 


Hex. Dec. 


eed 


0 —60 $VERSION 


HASP Version 





8 8 
Entry to HASP Dispatcher 
C 12 _ $GETBUF 
Entry to HASP Buffer "GET" Routine 
10 16 — $GETPBUF 
Entry to HASP RJE Buffer "GET" Routine 
14 20 $FREEBUF 
Entry to HASP Buffer "FREE" Routine 
18 24 $GETUNIT 
Entry to HASP Unit "GET" Routine 
1c 28 $FREUNIT 
Entry to HASP Unit "FREE" Routine 
20 32 $QADD 
Entry to HASP Job Queue Element "ADD" Routine 
24 36 $QGET 
Entry to HASP Job Queue Element "GET" Routine 
28 40 
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Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 
Displacement 
----------------------- 4A bytes, Heer este eens res e oe Se 
Hex. Dec. 





— 28 40 $QPUT 


Entry to HASP Job Queue Element "PUT" Routine 


2C 44 $QREM 


Entry to HASP Job Queue Element "REMOVE" Routine 


30 48 
Entry to HASP Job Queue "SIZE" Routine 
34 52 $QLOC 
Entry to HASP Job Queue Element "LOCATE" Routine 
38 56 $QJITLOC 
Entry to HASP JIT Element "LOCATE" Routine 
3C-——“‘éCS $TRACK 
Entry to HASP Track Allocation Routine 
40 64 $PURGER 
Entry to HASP Track Purge Routine 
44 68 $EXCP 
Entry to HASP Input/Output Supervisor 
48 72 $EXTPOPE 
Entry to HASP RTAM Open Routine 
4c 76 $EXTPGET 
Entry to HASP RTAM Get Routine 





50 80 
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HAS P 


Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 
Displacement | | | _ | | 
Sr Sse SS eee ee eS ‘+: DY CES: SHS eee si are Ses eras ees 
Hex. Dec. | 
50 80 | $EXTPPUT 
Entry to HASP RTAM Put Routine 
54 84 | S$EXTPCLO 


Entry to HASP RTAM Close Routine 


58 88  $RESTORE 


Entry to HASP RTAM Restore Routine 


SC 92 $ODEL 


Entry to HASP Overlay $DELETE Routine 





60 96 

Entry to HASP Overlay $RETURN Routine 
64 100 $OLINK 

Entry to HASP Overlay S$LINK Routine 
68 104 $OXCTL. 

Entry to HASP Overlay $XCTL Routine 
6C 108 $OLOAD 

Entry to HASP Overlay $LOAD Routine 
70 2=— 112 $WTO 

Entry to HASP Write-to-Operator Routine 
74 116  $FREEMSG 
Entry to HASP Console Message Buffer Free Routine 

78 120 
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Nl AS P 


Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement 






































































































PS Sa SS re ee 4 DVUGS. = S53) 2 S24e Sesser s ee >= 
Hex. Dec. 
78 = 120 $STIMER 
Entry to HASP Set Interval Timer Routine 
7C 124 $TTIMER 
Entry to HASP Test Interval Timer Routine 
80 128 $10ERROR | 
Entry to HASP Input/Output Error Logging Routine 
84 132 S$ERROR 
Entry to HASP Catastrophic Error Routine 
88 136 $DISTERR 
Entry to HASP Disastrous Error Routine 
8C 140 $SYSTYPE SOPTSTAT $STATUS 
System Type Initialization! HASP RESERVED 
MFT or MVT Options Status 
90 144 $HASPECF MHASPECB $XEQACT $ACTIVE 
Master Event RJE Event O/S Execution Active 
Control Field| Control Field Count Count 
94 148 $ENBALL $DISALL $DISINT: 
Enable All Disable All Disable Int RESERVED 
Mask Mask Timer Mask 
98 152 $PSRDRCT $PSPRFCT. $PSPUFCT 
Pseudo Reader | Pseudo Printer| Pseudo Punch RESERVED 
!Count (2540) Count (1443)} Count (1442) 
9C 156 $EXCPCT $COMMCT 
Active I/O Count Active Command Count 
AO 160 
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Ue AS oP 


Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement 


Hex. 


AO 


A4 


A8 


AC 


BO 


B4 


B8 


BC 


CO 


C4 


C8 


Dec. 


160 


164 


168 


172 


176— 


180 


184 


188 


196 


200 





$CKPTRAK 


Checkpoint Track RESERV E D 


$HASPTCB 


Address of HASP Task Control Block 


$PCEORG 


Address of First HASP Processor Control Element 


$BUF POOL 


Address of First Available HASP Buffer 


$TPBPOOL 


Address of First Available HASP RJE Buffer 


$DCTPOOL 


Address of First HASP Device Control Table 


$JITABLE 


Address of HASP Job Information Table 


$CYLMAP 


Address of First HASP Cylinder Module Map 





$TEDADDR 


Address of First Track Extent Data Table 


$DCBLIST 


Address of HASP Direct Access DCB 


HASP Communication Table Format -- Page 8.1-5 


510 


HAS 


Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement 


Hex. 


C8 


CC 


DO 


D4 


D8 


DC 


Dec. 


Senate eemameead 


200 


204 


208 


212 


216 


220 


$FREEQUE 


Address of First Free HASP Console Message Buffer 


SBUSYQUE 


Console Message Buffers Queued for I/O 


$LOGQUE 


Console Message Buffers Queued for Log Processor 


$COMMQUE 


HASP Commands Queued for Command Processor 


$PRCHKPT 


Address of HASP Print Checkpoint Table 





HASP Communication Table Format -- Page 8.1-6 


oe aE 


H AS P 


Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 
Displacement : 
SSS SSS See eee SS A bY CGS SH SSee Sess sess aSeer esses 
Hex. Dec. a | | | 


DC 220 ~~ $SVCRELT. 


Address of MFT SVC Relocation Table 


EO 224  $SVCTABF 
Address of MFT SVC Table 


E4 228 $SVCTABV 
Address of MVT SVC Table 


E8 232 | - $IOSENT 


Entry to O/S Input/Output Supervisor 


EC 236  $ATTNENT 


Entry to IOS Attention Appendage 


FO 240 $XSMFENT 


Entry to SMF EXCP Counting Routine 


F4 244: $SVRSET 


Entry to HASP SVC Reset Routine 





F8 248 
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NUCLEUS ADDRESS TABLE 


Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement 








eae ore nn ane eminem «DV CES Stare SaaS ee SHS Sk eS 
Hex. Dec. 
F8 248 $WAITENT 
Entry to IGCO01 (WAIT) 
FC 252 $LINKENT 
IGC006 
100 256 $XCTLENT 
IGC007 (XCTL) 
104 260 $TIMENT 
Entry to IGCO11 (TIME) 
108 264 $SVCIOS 
Address of EXCP SVC Table Entry 
LOC 268 $SVCLINK 
Address of LINK SVC Table Entry 
110 272 $SVCWTO 
WTO/WTOR SVC Table Entry 
114 276 $SVCWTL 
WTL SVC Table Entry 
118 280 $ATTNSAV 
12-Byte Attention Appendage Save Area 





124 292 
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EXTENDED NUCLEUS ADDRESS TABLE 


H-A S P 


Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 
Displacement 
? oS SS SSS SSeS ae 4. DVCCS: SSeS SaSeene See STS 


Hex, Dec. 


124 292 $ JOBQPTR 


Address of HASP Job Queue 


128 296 | $JQFREE 


Beginning of Free Job Queue Element Chain 


12c = 300  $JQENT 


Beginning of Active Job Queue Element Chain — 





130 304 $XEQTOTL 


Cumulative Estimated Execution Time 


134 308 $PRTTOTL 


Cumulative Lines to be Printed 


138 312) | = =$PUNTOTL 


Cumulative Cards to be Punched 


FE 
fy 
an 
oy 
fx 
>. 
KG 
n 
E4 
a 
ar 
O 
Ay 
we 
OU 
fx) 
oly 
UO 


13C 316 $JOBNO | $MSGRPNO 


HASP Job Number Last Console Track 





—$DACKPT 


140 320 


Variable Length DA Checkpoint Area. 
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Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 
0 0 $VERSION HASP Version ("V v.m "). 
8 8 $WAIT Entry to HASP Dispatcher. 
Cc 12 $GETBUF Entry to HASP Buffer "GET" Routine. 
‘10 | 16 $GETPBUF Entry to HASP RJE Buffer "GET" Routine. 
14 20 /$FREEBUF Entry to HASP Buffer “FREE" Routine. 
18 24 $GETUNIT Entry to HASP Unit "GET" Routine. 
Ake 28 $SFREUNIT Entry to HASP Unit "FREE" Routine. 
20 32 $QADD eneey to HASP Job Queue Element "ADD" Routine. 
24 36 $QGET entry to HASP Job Queue Element "GET" Routine. 
28 40 $QPUT re to HASP Job Queue Element "PUT" Routine. 
2c 44 $QREM Entry to HASP Job Queue Element "REMOVE" 
Routine. 
30 =. 48 $QSIZ Entry to HASP Job Queue "SIZE" Routine. 
34 52 $QLOC ny to HASP Job Queue Element "LOCATE" 
Routine. 
38 56 $QJITLOC mney to HASP Job Information Table Element 
"LOCATE" Routine. 
3C 60 $TRACK Entry to HASP Track Allocation Routine. 
40 64 $PURGER Entry to HASP Track Purge Routine. 
44 68 $EXCP Entry to HASP Input/Output Seaver laos 
48 72 $EXTPOPE Entry to HASP RTAM Open Routine. 
4c 76 $EXTPGET Entry to HASP RTAM Get Routine. . 
50 80 | SEXTPPUT Entry to HASP RTAM Put Routine. 
54 84 $EXTPOPE Entry to HASP RTAM Close Routine. 
58) 88 $RESTORE Entry to HASP RTAM Restore Routine. 


HASP Communication 
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Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes 


Hex. Dec. 


5c 


60 


64 


68 


6C 


70 


74 
78 
ie 


80 


84 
88 


8C 


8D 


92 


96 


100 


104 


108 


Li2 


116 


120° 
124 


128 


132... 


136 


140 


141 


$ODEL 


Field Description 


Overlay $DELETE Routine. 


4 ° Entry to HASP 
$ORET 4 Entry to HASP Overlay $RETURN Routine. 
$OLINK 4 Entry to HASP Overlay $LINK Routine. 
$OXCTL 4 Entry to HASP Overlay $XCTL Routine. 
$OLOAD 4 Entry to HASP Overlay $LOAD Routine. 
$WTO 4 Entry to HASP Write-to-Operator Routine. 
SFREEMSG 4 Entry to HASP Console Message Buffer 
. Free Routine. | | 
$STIMER 4 Entry to HASP Set Interval Timer Routine. 
$TTIMER 4 Entry to HASP Test Interval Timer Routine. 
~$IOERROR - 4 Entry to HASP Input/Output Error Logging 
| Routine. 
$ERROR 4 Entry to HASP Catastrophic Error Routine. 
$DISTERR 4 Entry to HASP Disastrous Error Routine. 
$SYSTYPE 1 System Type -- 
Hex. 
Value Meaning 
10 MVT 
14 MPS 
20 MFT 
$OPTSTAT | 1 Initialization Options -- 
Bit Name Meaning 
O  $OPTFMT FORMAT. 
1 $0PTCOLD COLD. : 
2 $O0PTREQ REQ. 
3. $O0PTREP ~ REP. 
4 $OPTLIST LIST. 
5 $0PTRACE TRACE. | 
6-7 Reserved for Future Use. 
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Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. 


8E 142 $STATUS 1 HASP Status -- 
Bit Name Meaning 


O $RDRPEND O/S Reader is Pending. 

1 $ALMSGSW ALL AVAILABLE FUNCTIONS 
COMPLETE Message has been 
Issued. 

2 $DRAINED System has been $DRAINed. 

$CKPTACT Checkpoint is in Progress. 

4 $JITCKPT Job Information Table (JIT) 
is to be Checkpointed. 

5 $SYSEXIT HASP System is in termination 


W 


process. | 
6-7 | | Reserved for Future Use. 
SF 143 1 Reserved for Future Use. 
90 144 ' SHASPECF 1 Master Event Control Field -- 
Bit Name Meaning 
0 S$EWFPOST A PCE has been $POSTed. 
1 SEWFBUF A Buffer has been Released. 
2 $EWFTRAK A Direct-Access Track has 


been Released. 
3 $EWFJOB A Job Queue Element has 
Changed Status. 
4 $EWFUNIT A HASP Unit has been Released. 
5  $EWFCKPT A HASP Checkpoint has Completed. 
6  $EWFCMB A Console Message Buffer has 
been Released. 
7  $EWF8 Reserved for Future Use. 


91 145 MHASPECF 1 Remote Job Entry Line Manager Event 
Control Field -- 


Bit Name Meaning 


0-2 | Reserved - Must be Zero. 

3 $EWFJOB A Job Queue Element has 
Changed Status. 

4-7 Reserved - Must be Zero. 
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Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes 


Hex. Dec. 


92 
93 
94 
95 
96 
97 
98 
99 
9A 
9B 


9C 


9E 


AO 


A2 


A4 


AB 


AC 


BO 


B4 
B8 
BC 


CO 


146 


147 


148 


149 


150 


151 
152 
153 
154 


155 


156 


158 


160 


162. 


164 


168 


172 
176 
180 
184 
188 


192 


Field Description 


Count of Jobs in O/S Execution Phase. 


$XEQACT 1 
$ACTIVE 1 Count of Active Processors. 
SENBALL 1 SENABLE ALL age (X'FF'). 
$DISALL. 1 SDISABLE ALL Mask (X'00'). 
$SDISINT a SDISABLE INT Mask (X'FE'). 
| 4 Reserved for Future Use. 
$PSRDRCT 1 Count of Pseudo 2540 Readers. 
$PSPRFCT 1 esint of Pseudo 1443 Printers. 
$PSPUFCT 1 Count of Pseudo 1442 Punches. 
| 1 Reserved for Future Use. 
$EXCPCT 2 Count of Active I/O sueveuione: 
$COMMCT 2 iiameuse Console Message Buffers which. 
are not Queued for the HASP Command Processor. 
$CKPTRAK 2 Gheseoint Track. 
2 Raserved: for Putuve se 
$HASPTCB | 4 Address of HASP Task Control Block. 
$PCEORG 4 Address of First HASP Processor Control 
| Element. | 7 : 
$BUFPOOL 4 Address of First Available HASP Buffer. 
$TPBPOOL 4 Address of First Available HASP RJE Buffer. 
$DCTPOOL 4 Address of First HASP Device Control Table. 
$JITABLE 4 Address of HASP Job Information Table. 
| $CYLMAP 4 Address of First HASP Track Allocation Map. 
STEDADDR 4 Address of First Track Extent Data Table. 
HASP Connan beaeion. ebae Format -~- Page 8.,1-13 
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Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. | 


mer RN 


C4 196 $DCBLIST 4 Address of HASP Direct Access DCB. 


C8 200 $FREEQUE 4 Address of First Free HASP Console 
3 Message Buffer. 


CC 204 $BUSYQUE #4. #£4xAddress of First Console Message Buffer 
which is Queued for I/O. 


DO 208 - $LOGQUE 4 Address of First Console Message Buffer 
a .e which is Queued for the Log Processor. 


D4 ° 212  $COMMQUE 4 Address of First Console Message Buffer 
which is Queued for the Command Processor. 


D8 216 $PRCHKPT | 4 Rageess of HASP Print Checkpoint Table. 

DC 220 $SVCRELT 4 “aGaeeas of MFT SVC Relocation Table. 

EO 224 $SVCTABF 4 adaéss of MFT SVC Table. 

E4 228 _ $SVCTABV | 4 re of MVT SVC Table. 

_E8 232 | $IOSENT 4 ” aaeesee of Entry to O/S Input /output 

Beg “. 2 ; 7 Supervisor. 

EC 236 $ATTNENT 4 Address of Entry to IOS Attention Appendage. 
FO 240 $XSMFEMT 4 Address of Entry to SMF EXCP Counting 

7 Routine. 

F4 244 $SVRSET 4 Address of Entry to HASP SVC Reset Routine. 
F8 248 — $WAITENT 4 Address of Entry to IGCOOl (WAIT). 

FC 252 $LINKENT 4 Address of Entry to IGCOO6 (LINK). 

100 256 $XCTLENT 4 Address of Entry to IGCOO7 (XCTL). 
104 260 $TIMENT 4 Address of Entry to IGCO11 (TIME). 

108 264 $SVCIOS 4 Address of EXCP SVC Table Entry. 

10C 268 $SVCLINK 4 Address of LINK SVC Table Entry. 

HASP Communication Table Format --- Page 8.1-14 


C 


519 


HAS P 


Figure 8.1.1 -- HASP COMMUNICATION TABLE FORMAT (CONTINUED) 


Displacement Field Name 


Dec. 


Hex. 
110 
114 
118 
124 
128 

-12¢ 
130 
134 
138 
13C 
13E 


140 


272 


276 


— 280 


292 


296 


300 


304 


308 
312 


316 


318 


320 


$SVCWTO 


$SVCWTL 


SATTNSAV | 


$JOBQPTR 


 $JQFREE 
$JQENT 
$XEQTOTL 


$PRTTOTL 
$PUNTOTL 


-$JOBNO 


$MSGRPNO 


$DACKPT 


Bytes Field Description — 


4 


4 


12 


_WTO/WTOR SVC Table Entry. 


WIL SVC Table Entry. 

Attention Appendage Save Area. 

Address of HASP Job Saaua 

Beginning of Free Job Queue Element Chain. 
Bes nRiAG of Active Job Queue Element Chain. 
Cumulative Estimated Execution Time. 
Cumulative Lines to be printed. 

eanuiacive Cards to be Punched. 

HASP Job Number: 


Last Remote Console Message Queueing Track. 


Variable Length Direct Access Checkpoint Area. 
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Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT 


Displacement 


Hex. 


0 


10 


14 


18 


1c 


20 


24 


28 


Dec. 


0 


12 


16 


20 


24 


28 


32 


36. 


40 





PCESAVEA 


RES ERVE D 


PCEPREV 


Address of Previous Processor Control Element 


PCENEXT 


Address of Next Processor Control Element 


PCELINK 


Processor Register 14 (LINK) Storage 


PCERLS5 


Processor Register 15 Storage 


PCERO 

Processor Register 0 Storage 
PCER1 

Processor Register 1 Storage 
PCEWA 


Processor Register 2 (WA) Storage 


Processor Register 3 (WB) Storage 





PCEWC 


Processor Register 4 (WC) Storage 


* 
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Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT (CONTINUED) 


Displacement - 


Hex. Dec. 


ereeteerremere poee 












































28 40 
Processor Register 5 (WD) Storage 
2C 44 
Processor Register 6 (WE) Storage 
30 48 
Processor Register 7 (WF) Storage 
34 52 PCEWG 
PCEBASE3 
Processor Register 8 (WG or BASE3) Storage 
38 56 PCER9 
Processor Register 9 Storage 
3C 60 | PCEJCT 
Processor Register 10 (JCT) Storage 
40 64 | PCEBASEL 
Processor Register 11 (BASE1) Storage 
44 68 PCEBASE2 
Processor Register 12 (BASE2) Storage 
48 72 PCEEWF PCEID 
Event Wait Field Processor Type. 
4c 76 PCEQPRIO PCEQCON 
RESERVED Overlay | Overlay Routine OCON 
Priority | | 
50 80 
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Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT (CONTINUED) 


Displacement 


Hex. 


50 


54 


58 


84 


88 


PCEORTRN 


Overlay Supervisor Register 14 (LINK) Storage 


PCEOPCE 


Chain of PCEs Using Same Overlay Routine 


PCEWORK 





Variable Length Processor Work Area 


Processor Control Element Format -- Page 8.2-3 


223 


A Se 


Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. a - 


6) 0 PCESAVEA 4  ~ Reserved. 
4 4 PCEPREV 4 Address of Previous Processor Control 
| Element. 
8 8 PCENEXT #44 Address of Next Processor Control Element. 
Cc 6012 PCELINK 4 Processor Register 14 (LINK) Storage. 
10 16 PCER15 | 4 Processor Register 15 Storage. 
14 20 ~ PCERO 4 Processor ee. Storage. 
18 24 PCERL 4 Processor Register 1 Storage. 
ic 28 PCEWA 4 Processor Register 2 (WA) Storage. 
20 32 PCEWB 4 Processor Register 3 (WB) Storage. 
24 36 ~ PCEWC 4 Processor Register 4 (WC) Storage. 
28 40 — PCEWD 4 Processor Register 5 (WD) Storage. 
 2C £44 PCEWE 4 Processor Register 6 (WE) Storage. 
30 3=6 48 PCEWF 4 Processor Register 7 (WF) Storage. 
34 52 PCEWG 4 Processor Register 8 (WG or BASE3) 
: PCEBASE3 Storage. 
38 56 PCERS 4 Processor Register 9 Storage. 
3C 3: 60 PCEJCT 4 Processor Register 10 (JCT) Storage. 
40 64 _ PCEBASEI 4 Processor Register 11 (BASE1) Storage. 
44 68 PCEBASE2 4 Processor Register 12 (BASE2) Seopaue. 


Processor Control Element Format -~- Page 8.2-4 
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Figure 8.2.1 -~- PROCESSOR CONTROL ELEMENT FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. 


48 72 PCEEWF 2 Event Wait Field -- 
Hex. 
Value Name Meaning 
Byte l 80 $EWFPOST Reserved. 


40 $EWFBUF Waiting for a Buffer. 

20 $EWFTRAK Waiting for HASP 
Direct-Access Space. 

10 $EWFJOB Waiting for a Job. 

08 $EWFUNIT Waiting for a Unit. 

04 $EWFCKPT Waiting for the completion 
of a HASP Checkpoint. 

02 $EWFCMB Waiting for a Console 
Message Buffer. 


Ol $EWFB Reserved for Future Use. 
Byte 2 80 $EWFOPER Waiting for Operator 
Response. 
40 $EWFIO Waiting for the Completion 
of I/O. 


20 $EWFWORK Waiting to be Re-directed. 
10 $EWFHOLD Waiting for a $S Command. 
08  $EWFDDB Waiting for a DDT or UCB. 
04 $EWFOLAY Waiting for an Overlay Area. 
02 $EWF15 Reserved for Future Use. 

Ol $EWFOROL Relingquished Overlay Area. 


4A 74 PCEID 2 Processor Type -- 
Bit Name Meaning 
Byte l O PCEPRSID Print Processor. 
| 1 PCEPUSID Punch Processor. 
2-4 Reserved for Future Use. 


5 PCEINRID Internal Reader Processor. 
6 PCERJEID Remote Terminal Processor. 
7 PCELCLID Local Processor. 
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Figure 8.2.1 -- PROCESSOR CONTROL ELEMENT FORMAT (CONTINUED) 


Displacement Field Name 
Hex. 


4C 
4D 


4E 


50 
54 


58 


Dec. 


76 


77 


78 


80 


84 


88 


PCEOPRIO 


PCEOCON 


PCEORTRN 
PCEOPCE 


PCEWORK 


Byte 2 


Bytes Field Description 


Processor Type (continued) -- 


Hex. 
Value 


00 
Ol 
03 
04 
05 
07 
08 
09 
OA 
OB 
OC 
OD 
OE 
OF 


Name 


PCEASYID 
PCERDRID 
PCEXEQID 
PCETHWID 
PCEXZMID 
PCEPRTID 
PCEPUNID 
PCEPRGID 
PCECONID 
PCEMLMID 
PCETIMID 
PCECKPID 
PCEGPRID 
PCEOROID 


Meaning 


ASYNCH Processor. 

Input Service Processor. 
Execution Service Processor. 
Execution Thaw Processor. _ 
Execution Task Monitor. 
Print Processor. 

Punch Processor. . 

Purge Processor. 

Console Processor. 

Line Manager Processor. 
Timer Processor. 

Checkpoint Processor. 
Priority Aging Processor. 
Overlay Roll Processor. 


Reserved for Future Use. 


Priority of Current Overlay Routine. 


Overlay Constant (OCON) of Current Overlay 
Routine. : 


Overlay Supervisor Register 14 (LINK) Storage. 


Chain of PCES Using Same Overlay Routine. | 


Variable Length Processor Work Area. 
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Figure 8.3.1 -- BUFFER FORMAT 


Displacement 


Hex. Dec. 


0 0 IOBFLAGI IOBFLAG2 IOBSENSO IOBSENS1 


I/O Flags I/O Flags First | Second 
Sense Byte Sense Byte 


4 4 IOBECBPT 


IOBECBCC Address of HASP Event Control Block 


8 8 IOBFLAG3 IOBCSW 
1/O Flags 


Channel Status Word 


10 16 IOBSTART 


IOBSIOCC Address of Channel Program 


14 20 IOBDCBPT 


Address of Data Control Block 


18 24 IOBRESTR 


IOBREPM Restart Address of Channel Program 


1c 28 IOBINCAM | TOBERRCT 


Block Count Increment Error Count 


20 32 TOBXTENT IOBSEEK 
Extent Index 


Seek Address (Direct-Access Only) 





28 40 


Buffer Format -~ Page 8.3-l 
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Figure 8.3.1 -- BUFFER FORMAT (CONTINUED) 


Displacement 


Hex. 


28 


ase 


30 


34 


38 


40 


48 


50 


Dec. 


40 


44 


48 


52 


56 


64 


72 


80 


~ BUFCHAIN 


BUFECBCC Buffer Chain Field 


BUFDCT 


| BUFTYPE Address of Device Control Table 


BUFEWF 


Event Wait Field or Post Address 


RES ERV ED 


LOBCCWA 


Channel Command Word 1 


IOBCCW2 


Channel Command Word 2 


IOBCCW3 


Channel Command Word 3 
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Figure 8.3.1 -- BUFFER FORMAT (CONTINUED) 


Displacement | 


Hex. Dec. 


50 80 BUFSTART 


Variable Length Buffer 
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Figure 8.3.1 -- BUFFER FORMAT (CONTINUED) 


Displacement Field Name 
Dec. 


Hex. 


0 


10 


10 


14 


18 


18 


LC 


1E 


20 


O 


16 
16 
20 


24 


24 


28 
30 


32 


[OBFLAGL 
[OBFLAG2 
IOBSENSO 


TOBSENS1L 


-IOBECBCC 


IOBECBPT 


TOBFLAG3 


IOBCSW ~ 


. TOBSTOCC. 


IOBSTART 


TOBDCBPT 


IOBREPM 


TOBRESTR 


TOBINCAM 


TOBERRCT 


TOBXTENT 


Field Description 


Standard OS/360 IOB Flag Byte. 
Standard OS/360 IOB Flag Byte. 
First Sense Byte (Device Dependent). 
Second Sense Byte (Device Dependent). 
Completion Code for I/O Event. 


Address of HASP Event Control Block: 
SHASPECB. 


I/O Supervisor Error Routine Flag Byte 
(Device Dependent). 


Low~Order Seven Bytes of the Last CSW 
that. Reflects the Status of the 
Last Request. 


Condition Code Returned after Execution 
of SIO Instruction for Last Request. 


Address of Channel Program to be 
Executed. 


Address of Data Control Block Associated 
with this IOB. 


Operation Code Used by I/O Supervisor 
Error Routines for Repositioning 
Procedures. 

Restart Address of Channel Program Used 
by I/O Supervisor Error Routines During 


Error Correction. 


Value used to Increment Block Count 
Field in DCB for Magnetic Tape. 


Used by I/O Supervisor Error Routines 
to Count Temporary Errors during Retry. 


The Number of the DEB Extent to be 
Used for this Request. 
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Figure 8.3.1 -- BUFFER FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. 


21 


28 


28 


2C 


2C 


30 
34 
38 
40 
48 


50 


Dec. 


33 


40 


40 


44 


44 


48 


52 


56 


64 


72 


80 


TOBSEEK 


BUFECBCC 


BUFCHAIN 


BUFTYPE 


BUFDCT 


BUFEWF 


TOBCCW1L 
TOBCCW2 
TOBCCW3 


BUFSTART 


5 


Seek Address Required for this I/O 
Request (Direct-Access Only). 


Completion Code for I/O Event -- 


Hex. 
Value Meaning 


00 The I/O Event has not Completed. 
7F The I/O Event has Completed 
Successfully. 
other The I/O Event has Completed 
Unsuccessfully. 
Buffer Chain Field. 
Buffer Type -- 


Hex. 
Value Name Meaning 


00 HASPBUF HASP Buffer 


Address of Device Control Table Associated 
with this I/O Request. 


Event Wait Field or Post Address. 
Reserved for Future Use. 
Channel Command Word l. 
Channel Command Word 2. 
Channel Command Word 3. 


Variable Length Buffer. 
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Fiqure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT 


Displacement 


Hex. De 


10 


14 


18 


1c 


20 


24 


28 


16 


20 


24 


28 


32 


36 


40 


1OBFLAG1 IOBFLAG2 IOBSENSO IOBSENS1 


I/O Flags | I/O Flags First Second 
Sense Byte | Sense Byte 





IOBECBPT 





, HAS) ? lock 
IOBECBCC Address of HASP Event Control Bloc 
IOBCSW 
RESERVED 
Channel Status Word 
IOBSTART 
| IOBSIOCC Address of Channel Program 
IOBDCBPT 
Address of Data Control Block 
IOBRESTR 


Address of First CCW in Channel Program 






TPBMXREC 






Maximum RES ERV ED 


Record Count | 







TBPLCCAD 





Pes secs gates 







TPBLCCC Address of Last Remote Carriage Control 


TPBFDATA 


TPBRECNT | 





Remote Data Pointer 
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Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED) 


Displacement 


Hex. 


28 


2C 


30 


34 


38 


40 


48 


50 


Dec. 


40 


44 


48 


52 


56 


64 


72 


B0 


ae enw aw ew a a ee ew am er ae ew 


BUFCHAIN 


BUFECBCC 


BUFDCT 
BUFTYPE 


BUFEWF 


LCBMCB 


Mode Byte 


IOBCCWL 


IOBCCW2 


IOBCCW3 


a ee ee em om oe em a a cn ene 


Buffer Chain Field 


Address of Line DCT 


Address of Event Wait Field 


LCBACK 


Next 
Acknowledge 


LCBRCB 


Response Control Block 


Channel Command Word 1 


MSEQTYPE | 





Channel Command Word 2 


Channel Command Word 3 


533 
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Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED) 


Displacement 
Hex. Dec. r 


50 80 |  IOBCCW4 


Channel Command Word 


58 88 IOBCCW5 


Channel Command Word 


60 96 IOBCCW6 


Channel Command Word 


68 104 IOBCCW7 


Channel Command Word 


70 8112 IOBCCW8 


Channel Command Word 





78 120 
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Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED) 


Displacement 


Hex. Dec. 





78 120 TPBUFST 


Variable Length Buffer 
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Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED) 


‘Displacement Field Name Bytes 
Dec. | 


Hex. 


0 


10 


10 


14 
18 


“Ac 
1D 
20 
20° 
24 
24 
28 


28 


0 


Hy 


16 


16 


20 


24 


28 


29 


32 


32 


36 


36 


40 


40 


IOBFLAGL 
TOBFLAG2 


TOBSENSO 


— TOBSENS1 


TOBECBCC 


-IOBECBPT 


TOBCSW 


TOBSTOCC 


- LOBSTART 


IOBDCBPT 


TOBRESTR 


TPBMXREC 


TPBLCCC 


- TPBLCCAD 


TPBRECNT 
TPBFDATA 


BUFECBCC 


BUFCHAIN. 


Field Description 


Standard OS/360 IOB Flag Byte. 
Standard OS/360 IOB Flag Byte. 
First Sieee Byte (Device Dependent). 
Second Sense Byte (Device bependeney: 
Completion Code for I/O Event. 


Address of HASP Event Control Block: 
SHASPECB. - 


Reserved. 

Low Order Seven Bytes of the Last CSW 
that Reflects the Status of the Last 

Request. 


Condition Code Returned after Execution 
of SIO Instruction for Last Request 


Address of Channel Program to be Executed. 


Address of Data Control Block Associated 
with this IOB. 


Address of Normal Channel Program to be 
Executed. 


Maximum Output Record Count. 
Reserved for Future Use. 


Last Output Channel Command Operation. 


Address of Last Remote Carriage Control. 


Current Output Record Count. 


Address of Next Data in Buffer. 


Completion Code for I/O Event. 


Buffer Chain Field. 


Buffer Format -- Page 8.3-10 
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Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED) 
Displacement Field Name Bytes Field Description 
Hex. Dec. 
2c 44 BUFTYPE 1 Buffer Type -- 
Hex. 
Value Name Meaning 
80 TPBUF Remote Job Entry Buffer 
2C 44 BUFDCT 4 Address of Line Device Control Table 
| Associated with this I/O Request. 
30 48 BUFEWF 4 Address of Event Wait Field. 
34 52 LCBMCB 1 Mode Byte Used to Set SDA Mode. 
35 53 LCBACK 1 BSC: Next Acknowledgement Character 
| (Expected or to be Sent). 
STR: Second Mode Byte. 
36 54 LCBRCB 2 BSC: Response Control Block. 
STR: Unused. 
38 56 IOBCCW1 8 Channel Command Word 1. 
3D Bt _MSEQTYPE 1 Sequence and Command Type -- 
Bits 0-3 Sequence Type 


Bit Name Value Meaning 
O MBSCSEQ 0 STR Sequence. 
1 BSC Sequence. 
1 MPREPSEQ O Text Sequence. 
| 1 Prepare Sequence. 
2 MWRITSEQ 0 Read Sequence. 
| i Write Sequence. 
3 MCPUSEQ 0 Hardware Sequence. 
1 CPU Sequence. 
Buffer Format -- Page 8.3-11l 
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Figure 8.3.2 -- REMOTE JOB ENTRY BUFFER FORMAT (CONTINUED) 


Displacement Field Name Bytes 
Dec. 


Hex. 


40 
48 
50 
58 
60 


68 


70 


78 


64 


72 


80 


88 


96 


104 


112 


120 


TOBCCw2 


TOBCCW3 


~TOBCCW4 


TOBCCW5 
IOBCCW6 
IOBCCW7 
IOBCCW8 


TPBUFST 


Bits 4-7 


Field Description 


Sequence and Command Type (continued) -- 


Command Type 


Hex. 


Value. 


OPrPwowonrnoaunr wnt O 


Channel 
Channel 
Channel 
Channel 
Channel 
Channel 
Channel 


Variabl 


538 


Name 


MDISCMD 
MSETMCMD 
MENBCMD 
MTSYNCMD 
MREADCMD 


MRRSPCMD | 


MRREQCMD 
MPREPCMD 


MWRITCMD 


MWRSPCMD 
MWENQCMD 
MSEOTCMD 
Command 
Command 
Command 
Command 
Command 
soancne 


Command 


e Length 


Meaning 


Disable Command. 

Set Mode Command. 
Enable Command. 

Test Synch Command. 
Read Text Command. 

Read Response (Normal). 
Read Response (To ENQ). 
Prepare Command. 

Write Text Command. 
Write Response Command. 
Send Inquiry Command. 
Send EOT Command. 


Word 2. 
Word 3. 
Word 4. 
Word 5. 
Word 6. 
Word 7. 
Word 8. 


Buffer. 


Buffer Format -- Page 8.3-12 
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Figure 8.3.3 -- OVERLAY AREA FORMAT 


Displacement 
















a a a aaa a a DV Les. SSeSsoSs Sse ser rT aT 
Hex. Dec. 
0. . 0 IOBFLAGI IOBFLAG2 — : IOBSENSO IOBSENSIL 
I/O Flags I/O Flags First Second 
_ Sense Byte Sense Byte 
4 4 IOBECBPT 
 IOBECBCC Address of HASP Event Control Block 
8 ~—8 IOBFLAG3 IOBCSW. 
I/O Flags 
Channel Status Word 
10 16 IOBSTART 
IOBSIOCC Address of Channel Program 
14 20 IOBDCBPT 
Address of Data Control Block 
18 24 IOBRESTR 
LOBREPM Restart Address of Channel Program 
Le 28 IOBERRCT 
RES ERVED Error Count 
20. 32, LOBXTENT IOBSEEK 
Extent Index 
Seek Address 
28 40 


Buffer Format -- Page 8.3-13 
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Figure 8.3.3 -- OVERLAY AREA FORMAT (CONTINUED) 


Hex. Dec. 


Displacement - ! | 


28 40 BUFCHAIN 


. ° q da 
BUFECBCC Buffer Chain Fiel 





2c 44 BUFDCT 


BUFTYPE Address of OLAY DCT 





30 48 | BUFEWF 
Address of Overlay Service Asynchronous Exit 
34 52 | OACECHN 


Overlay Area Chain Word 


38 56 TOBCCWL 


Channel Command Word 1 


40 64 | IOBCCW2 


Channel Command Word 2 


44 68 | OACEPRIO OACEOCON 


RESERVED Overlay Overlay Call Constant 
Priority 


48 72 IOBCCW3 


Channel Command Word 3 





50 80 


Buffer Format -- Page 8.3-14 
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Figure 8.3.3 -- OVERLAY AREA FORMAT (CONTINUED) 


Displacement 


Hex. Dec. 


memrememmnene i 


50  ~——-80 OACENAME 


Name of Overlay Routine 


54 —B4 OACEASMO 


Assembly Origin of Overlay Routine 


58 88 OACEPROG 


Entry Point of Overlay Routine 


oC. « G2 


Variable Length Overlay Area 


OACEPCE 


Chain of PCEs Using Overlay Area 





Buffer Format -- Page 8.3-15 
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Figure 8.3.3 -- OVERLAY AREA FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 


0 0 Standard OS/360 IOB Flag Byte. 
a—- o IOBFLAG2 Standard OS/360 IOB Flag Byte. 
2 2 IOBSENSO First Sense Byte (Device Dependent). 
3 3 IOBSENS1 Second Sense Byte (Device Dependent) . 
4 4 TOBECBCC | Completion Code for Overlay Read. 
4 4 TOBECBPT Address of HASP Event Control Block: 
| _ SHASPECB. | 
8 8 TOBFLAG3 I/O Supervisor Error Routine Flag Byte 
| | | 7 (Device Dependent). 
9 9 ~~ TOBCSW Low Order Seven Bytes of the Last CSW. 
that Reflects the Status of the Last Read. 
10 16 ~~ TOBSIOCC Condition Code Returned After the Execution 
| of the SIO Instruction for the Last Read. 
10 ° 16 IOBSTART Address of the Channel Program to be 
Executed. 
14 20 IOBDCBPT Address of the Data Control Block Associated 
with this IOB. 
18 24 ITOBREPM Operation Code Used by I/O Supervisor 
Error Routines for Repositioning Procedures. 
18 24 IOBRESTR Restart Address of Channel Program Used by 
- I/O Supervisor Error Routines During Error 
Correction. 
1c 28 | Reserved. 
1E 30 TOBERRCT — Used by I/O Supervisor Error Routines 
| to Count Temporary Errors During Retry. 
20 32 IOBXTENT The Number of the DEB Extent to be Used 
| for this Read. 3 
21 = 33 TOBSEEK The Seek Address for the Requested Overlay 


IOBFLAG1 


Routine. 


Buffer Format -- Page 8.3-16 


542 


fake S&S oP 


Figure 8.3.3 -- OVERLAY AREA FORMAT (CONTINUED) 


Displacement 


Hex. Dec. 


28 


28 


Ze 


30 


34 


38 


40 


44 


45 


46 


48 


50 


54 


58 


40 


40 


44 


44 


48 


32 


56 


64 


68 


69 


70 


72 


80 


84 


88 


Field Name 


BUFECBCC 


BUFCHAIN 


BUFTYPE 


BUFDCT 
BUFEWF 
OACECHN 
TOBCCWIL 


TOBCCW2 


OACEPRIO 


OACEOCON 


TOBCCW3 
OACENAME 
OACEASMO 


OACEPROG 


OACEPCE 


Bytes 


1 


nes 


Field Description 


Completion Code for Overlay Read -- 


Hex. 


Value Meaning 


00 The Read has not Completed. 

7F The Read has Completed Successfully. 
other The Read has Completed Unsuccessfully. 
Buffer Chain Field. 


Buffer Type -- 


Hex. 
Value Name Meaning 
40 OLAYBUF Overlay Area. 


Address of Overlay Device Control Table. 
Address of Overlay Service Asynchronous Exit. 
Overlay Area Chain Word. 

Channel Command Word l. 

Channel Command Word 2. 

Reserved for Future Use. 

Priority of Current Overlay Routine. 


Overlay Constant (OCON) of Current Overlay 
Routine. 


Channel Command Word 3. 

Name of Overlay Routine. 

Assembly Origin of Overlay Routine. 
oe Point of Overlay Routine. 
Variable Length Overlay Area 


Chain of PCEs Using Overlay Area. 


Buffer Format -- Page 8.3-17 
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Figure 8.4.1 -- CONSOLE MESSAGE BUFFER FORMAT 


Hex. Dec. 


Displacement - 


0 0 CMBCHAIN 


Address of Next Console Message Buffer 








4 4 CMBFLAGS CMBCONS CMBMSGL |  CMBPRIO 
: : CMBCLASS 
Flags Consoles Message | 
| Specified Length Prio & Class 
8 8 CMBMSG = «|| ~——s CMBMARK CMBT IME 
Start of Attention 
Message Indicator 
Cc 012 | 
Time of Day 
10 16 | CMBJOBNO 
14 20 
Job Number 
18 24 CMBTEXT 
1c 28 
112-Byte Message Text Area 
8C 140 


Console Message Buffer Format -- Page 8.4-1 
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Figure 8.4.1 -- CONSOLE MESSAGE BUFFER FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. 


0 0 CMBCHAIN 4 Address of Next Console Message Buffer. 
4 4 CMBFLAGS 1 Console Buffer Flags -- 
Bit Name Meaning 


0 WCMBFD CMBCONS Contains Physical 


Consoles. 
1 WCMBFH Operation Type. 
2 WCMBFE Message for HASP Log Only. 
3 WCMBFF CMBCONS Contains UCMID. 
4 WCMBFG CMBCONS Contains Remote No. 
5 WCMBFA Reserved for 
6 WCMBFB Command 
7 WCMBFC Processor. 
5 S CMBCONS a Console Specifications or Remote Number. 
6 6 CMBMSGL ug Message Length. 
7 7 CMBCLASS EE Message Class -- 
Bits 0-3 Value Name Meaning 


1 $TRIVIA  Non-Essential Messages. 

3 $NORMAL Normal Messages. 

5 $ACTION Messages Requiring 
Operator Action. 


qd $ALWAYS Essential Messages. 
CMBPRIO Message Priority -- 
Bits 4-7 Value Name Meaning 

i: $LO Low Priority. 
4 $ST Standard Priority. 
7 $HI High Priority. 

8 8 CMBMSG 132 Message Area. 

9 9 CMBMARK 1 Asterisk (*) if Message Class is 5 or More. 

A 10 CMBT IME 9 Time of Day (HH.MM.SS ). 

13: + «#19 CMBJOBNO 8 Job Number (If Applicable). 

1B 27 CMBTEXT 112 Message Text Area. 


Console Message Buffer Format -- Page 8.4-2 


545 





HAS P 


Figure 8.5.1 -- DIRECT-ACCESS DEVICE CONTROL TABLE FORMAT 


Displacement 
Hex. Dec. r 
0 0 DCTPCE 


DCTSTAT Address of Processor Control Element 


4 4 DCTBUFAD 


Current Buffer Address 


8 8 DCTSEEK 


Current Track Address 


C 12 DCTEWF 


Event Wait Field or Post Address 


10 16 DCTBUFCT | DCTDEVTP DCTIOTYP 


Active RESERVED Device Input/Output 
Buffer Count Type Request Type 


14 20 DCTCHAIN 


Address of Next Device Control Table 





18 24 


Device Control Table Format -- Page 8.5-l 
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Figure 8.5.1 -- DIRECT-ACCESS DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes’ Field Description. 


Hex. Dec. 
0 0. DCTSTAT 1 DCT Status -- 
Bit Name Meaning 


0  DCTINUSE DCT is In Use. 


1-7 Reserved. 
0 | 0 -DCTPCE | ~ 4 Address of Processor Control Element. 
4 4 DCTBUFAD 4 Address of Current Buffer. 
8 8 DCTSEEK ° 4 Current Track Address. 
C 12 DCTEWF 4 Event Wait Field or Post aGarese: 
10 16 ‘DCTBUFCT 1 Number of I/O Requests Outstanding. 
11 17 | ; nap oe Reserved for Future Use. . | 
12 18 DCTDEVTP. lo Device Type -- 

| Hex. 


Value Name Device Type | 


00 PDCTDA Direct-Access Device. 
13 19 DCTIOTYP 1 Input/Output Request Type -- 
Bit Name Meaning 


O DCTREAD - Read Request. 
1 DCTWRITE Write Request. 


2-7 Reserved for Future Use. 
14 20 | DCTCHAIN © 4: Address of Next Device. Control Table. 
_,Device Control Table Format -- Page 8.5-2 
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Figure 8.5.2 -- OVERLAY DEVICE CONTROL TABLE FORMAT 


Hex. Dec. 


Displacement - 


0 0 DCTPCE 


| DCTSTAT : Address of Overlay Roll PCE 


4 4 DCTBUFAD 


Address of Current Overlay Area 


8 8 DCTSEEK 


Overlay Track Address 


C 12 DCTEWF 


Address of Overlay Service Asynchronous Exit 


10 16 DCTBUFCT | | DCTDEVTP DCTIOTYP 


Active RESERVED Device | Input 
Buffer Count | Type Request Type 


14 20. DCTCHAIN 


Address of Next Device Control Table 


18 24 DCTDEVN 


-EBCDIC Device Name -- "OLAY" 


1c 28 DCTOTC DCTOTT 


Number of Tracks/Cylinder Overlay Extent Origin 





20 32 


Device Control Table Format -- Page 8.5-3 
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Figure 8.5.2 -- OVERLAY DEVICE CONTROL TABLE FORMAT (CONTINUED) 
Displacement Field Name Bytes Field Description 
Hex. Dec. 
O 0 DCTSTAT 1 DCT Status -- 
Bit | Name © Meaning 
O DCTINUSE DCT is In Use. 
1-7 Reserved. 
O O DCTPCE 4 Address of Overlay Roll PCE. 
4 4 DCTBUFAD 4 Address of Current Overlay Area. 
8 8 DCTSEEK 4 Overlay Track Address. 
C 12 DCTEWF 4 Address of Overlay Service Asynchronous 
Exit. 
10 16 DCTBUFCT 1 Number of I/O Requests Outstanding. 
ll eT Ll Reserved for Future Use. 
12 18 ~DCTDEVTP 1 Device Type -- 
Hex. 
Value Name Meaning 
00 DCTDA Overlay Data Set Resides 
on SPOOL Disk. 
Ol DCTOLAY Overlay Data Set does not 
Reside on SPOOL Disk. 
13 19 DCTIOTYP 1 Input Request Type -- 
Bit Name Meaning 
0 DCTREAD Read Request. 
1-7 Reserved for Future Use. 
14 20 “DCTCHAIN 4 Address of Next Device Control Table. 
18 24 DCTDEVN 4 EBCDIC Device Name -- "OLAY". 
1c 28 DCTOTC 2 Number of Tracks per Cylinder on Overlay 
. Direct-Access Device. 
1E 30 DCTOTT 2 Overlay Extent Origin. 
Device Control Table Format -- Page 8.5-4 
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Figure 8.5.3 ~~ UNIT RECORD DEVICE CONTROL TABLE FORMAT 


Displacement 


Hex. Dec. 


0 0 7 DCTPCE 


t 
DCTSTAT | Address of Processor Pon ens Elemen 


4 0 4 DC TBUFAD 


Current Buffer Address. 


8 8 DC TDCB 


Address of Data Control Block 


C 12 DC TEWF 


Event Wait Field or Post Address 


10 16 DC TBUFCT DCTNO DCTDEVTP DCTIOTYP 
Active DCT Device Device 
Buffer Count Number Type Type 
414 20 | DCTCHAIN 
DCTELAGS Address of Next Device Control Table 
18 24 DCTDEVN 


EBCDIC Device Name 








20 32 
DEVICES OTHER THAN PRINTERS AND PUNCHES 
20 32 DC TPRINT DCTPUNCH DCTPRINC DCTPRLIM 
| Print Punch Priority Priority 
Destination Destination Increment Limit 
24 =: 36 


Device Control Table Format -- Page 8.5-5 
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Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement 


Hex. Dec. 


eee 


PRINTERS AND PUNCHES 


20 32 DCTFORMS 








Current Forms Type (Packed) | Carriage Tape UCS Type 
24 36 
INTERNAL READERS 

24 36 | RIDUCB 

Address of Internal Reader UCB 
28 40 RIDFLAGS —  RIDCNT 

Synchronization Flags | TIC Count 

2C 44 RIDECB 

Address of Internal Reader 
30 48 RIDTCB 

Address of Internal Reader 
34 52 RIDCCW 

Address of Internal Reader 
38 56 | RIDDATA 

80-Byte Internal Reader Data 

88 136 


Device Control Table Format -- Page 8.5-6 
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Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED) 
Displacement . | | : 


Hex. Dec. 


PUNCHES 


24 36 DC TWORK 


80-Byte Error Recovery Save Area | 





74 116 


Device Control Table Format -- Page 8.5-7 
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Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED) 
Displacement Field Name Bytes Field Description 
Hex. Dec 
O. . 0 DCTSTAT 1 DCT Status -- 
Bit Name Meaning 
O DCTINUSE DCT is In Use. 
1: DCTDRAIN DCT is Drained. 
2 DCTHOLD DCT is Held. 
3-7 Reserved. 
O O DCTPCE 4 Address of Processor Control Element. 
4 4 DCTBUFAD 4 Current Buffer Address. 
8 8 DCTDCB 4 Address of Data Control Block 
for this Unit. 
GC 12 DCTEWF 4 Event Wait Field or Post Address. 
10 16 DCTBUFCT 1 Number of I/O Requests Outstanding. 
11 17 DCTNO 1 Device Number. 
12 18 DCTDEVTP uy Device Type -- 
Hex. 
Value Name Device Type 
10 DCTRDR Card Reader. 
11 DCTTPE Input Tape. 
14 DCTINR Internal Reader. 
20 DCTPRT Printer. 
30 DCTPUN Punch. 
40 DCTCON Console. 
13 19 DCTIOTYP 1 Device Type and Console Restrictions -- 
Bit Name Meaning 
0-1 Reserved. 
2 DCT1053 1053 Console. 
3 DCT2260 2260 Console. 
4 DCTREJRM — Reserved. 
5 DCTREJJB Job Command Restriction. 
6 DCTREJDV Device Command Restriction. 
7 DCTREJSY System Command Restriction. 





Device Control Table 


553 
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Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 
14 20 DCTFLAGS 1 | Operator Command Flags -- 
Bit Name Command 


0 DCTSTOP $Z (SSTOP) 

1 DCTDELET $c ($DELETE) 

2 DCTRSTRT SE (SRESTART) 

3 DCTRPT SN ($REPEAT) 

4 DCTBKSP SB (SBACKSPACE) 

SF 

5 DCTHOLDJ ST...,H 

DCTSPACE $T...,C=1 


2+4 $I 
6-7 Reserved for Future Use. 
14 20 DCTCHAIN 4 Address of Next Device Control Table. 
18 (24  — DCTDEVN 8 EBCDIC Device Name. . 
20 32 DCTPRINT 1 Print Destination. 
21 33 DCTPUNCH 1 Punch Destination. 
22 34 DCTPRINC 1 Priority Increment. 
23 35 DCTPRLIM 1 Priority Limit. 
20 32 DCTFORMS 2 Current Forms Type (Packed). 
22 34 | 7 1 Carriage Tape -- 
Bit Name Meaning 


0 DCTFSPEC Special Forms Routing. 
1 DCTFOPER Operator Controlled Forms. 


2-7 Carriage Tape Type. 
23 35 1 Universal Character Set -- 
Bit Name Meaning 
) DCTIDSEP Generate Separator Page/Card. 
1 Reserved for Future Use. 
2-7 | UCS Type. 
Device Control Table Format -- Page 8.5-9 
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Figure 8.5.3 -- UNIT RECORD DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 


eee 


24 36 RIDUCB ~ — 4 Address of Internal Reader UCB. 
28 40 RIDFLAGS 2 Synchronization Flags -- 
Byte l Bit Name Meaning 


0 RIDBUSY I/O Simulation in Progress. 


i al | Reserved for Future USe. 
Byte 2 Reserved for Future Use. 

2A 42 RIDCNT . 2 Count of Transfer-In-Channel Commands. 

2C 44 RIDECB 4 Address of Internal Reader ECB. 

30 48 RIDTCB 4 Address of Internal Reader TCB. 

34 52... RIDCCW 4 Adavews of Internal Reader CCW. 

38 56 RIDDATA 80 Internal Reader Data Area. 

24 36 DCTWORK 80 Punch Error Recovery Save Area. 


Device Control Table Format -- Page 8.5-10 
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Figure 8.5.4 -- LINE DEVICE CONTROL TABLE FORMAT 


Displacement 


Hex. Dec. 


























0 0 -DCTPCE 
: ; E 
| DCTSTAT Address of Line Manager PC 
4 4 DCTBUFAD 
Address of Line RJE Buffer 
8 8 DCTDCB 
5 ; : 
DCTPSTAT Address of Line Data Control Bloc 
Cc 12 | MDC TOBUF 
7 MDCTOPCT RJE Output Buffer Chain Field 
10 16 DCTBUFCT MDCTATTN DCTDEVTP DCTPCODE 
Active Attention Device | Line 
Buffer Count Indicator | Type _ Type 
14 20 DCTCHAIN 
DCTFLAGS peor eee of Next Device Control Table 
18 24 DCTDEVN 
EBCDIC Device Name 
20 32 MDC TCODE 
Address of RJE Code Table 
24 36 MDCTFCS MDCTERCT DCTPLINE 
Function Control Sequence Error Count Mode Byte 
28 40 


Device Control Table Format -- Page 8.5-11 
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Figure 8.5.4 -- LINE DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement 




















Pi ee Sma ere eee ee 4 DY LES: SS ereee Ses eee Serer 
Hex. Dec. 

28 40 MDCTDCT 

Address of First Remote DCT Attached to this Line 
2C 44 MDCTRSEQ MDCTTSEQ 

Receive Transmit RES ERVEOD 

Sequence Sequence 
30 48 MDCTPSWD 

Line Password 

38 56 


Device Control Table Format -- Page 8.5-12 
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Figure 8.5.4 -- LINE DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. 


0 


10 


11 


Dec. 


0 


12 


12 


16 


17 


DCTSTAT 


DCTPCE 


DCTBUFAD 


‘DCTPSTAT _ 


DCTDCB 

MDCTOPCT 
MDCTOBUF 
DCTBUFCT 
MDCTATTN 


DCT Status -- 
Bit Name 
0 DCT INUSE 
1 DCTDRAIN 
2-7 


Meaning 


DCT is In Use. 
DCT is Drained. 
Reserved. 


Address of Line Manager PCE. 


Address of Line RJE Buffer. 


Line Flags -- 
Bit Name 
O DCT LOGAL 
1 DCTLEASE 
2 DCTETX 
3 DCTSOFF 
4-7 


Meaning 


Log Every Channel End. 
Leased Line. 

An ETX has been Received. 
A /*SIGNOFF Card has been 
Processed. 

Reserved for Future Use. 


Address of Line Data Control Block. 


MULTI-LEAVING Terminal Open Count. 


RJE Output Buffer Chain Field. 


Number of I/O Requests Outstanding. 


Line Attention Requests -- 


Bit 


558 


Name 


MDCTIMER 
MDCTPAWS 


MDCT JOB1. 


MDCT JOB2 
MDCT JOB 


Device Control Table 


Meaning 


Timed Action Requested. 
Line Pause Requested. 
Job Post Indicator 1. 
Job Post Indicator 2. 
Job Post Indication. 
Reserved for Future Use. 


Format -- Page 8.5-13 
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Figure 8.5.4 -- LINE DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. . 


12 18 DCTDEVTP 1 Device Type -- 


Hex. 


Value Name Device Type 
02 DCTLNE Line. 


13 19 DCTPCODE 1 Line Type -- 
Bit Name Value Meaning 
0 DCTPBSC O STR Line. 
1 BSC Line. 
1 DCTPTRSP 0 No Transparency. 
1 Transparency. 
2 DCTPASCI O EBCDIC Code. 
ah USASCII Code. 
3 DCTPHASP Reserved. 
4-5 Reserved. 
6 DCTPWIDE 0 Low-Speed Line. 
rE Wide-Band Line. 
7 DCTPHALF 0 Half-Duplex Line. 
DCTPFULL 1 Full-Duplex Line. 
14 20 DCTFLAGS 1 Operator Command Flags -- 
Bit Name Command 
O-1 Reserved. 
2 DCTRSTRT SE (SRESTART) -- Abort. 
3-7 Reserved. 
14 20 DCTCHAIN 4 Address of Next Device Control Table. 
18 24 DCTDEVN 8 EBCDIC Device Name. 
20 32 MDCT CODE 4 Address of RJE Code Table. 
24 36 MDCTFCS 2 Last Function Control Sequence Received. 
26 38 MDCTERCT 1 Line Error Count/Indicator. 
27 39 DCTPLINE 1 SDA Mode Byte. 
| 28 40 MDCTDCT 4 Address of First Remote DCT Attached to 
this Line. 
Device Control Table Format -- Page 8.5-14 
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Figure 8.5.4 -- LINE DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. | 


2c 44 MDCTRSEQ a Receive Block Sequence Count. 
2D 45 MDCTTSEQ 1 Transmit Block Sequence Count. 
2E 46 2 ##Reserved for Future Use. 


30 48 MDCTPSWD 8 Line Password. 


Device Control Table Format -- Page 8,5-15 
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Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT 


Displacement 


Hex. 


10 


14 


18 


20 


20 


24 


Dec. 


12 


16 


20 


24 


32 


32 


36 





DCTPCE 


| DCTSTAT Address of Processor Control Element 


DC TBUFAD 


Address of Current RJE Buffer 


DCTDCB 


Address of Line Device Control Table 


DCTPSTAT 


DC TEWF 


Address of Event Wait Field 
DCTDEVTP DC TPCODE 


RESERVED Device |. Remote 
Type Code 


DCTCHAIN 


DCTFELAGS Address of Next Device Control Table 


DCTDEVN 


EBCDIC Device Name 


REMOTE READERS AND. REMOTE CONSOLES 


DCTPRINT DCTPUNCH DCTPRINC DCTPRLIM 


Print | Punch Priority Priority 
Destination Destination Increment Limit 





Device Control Table Format -- Page 8,5-16 
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Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement 


Hex. Dec. 


REMOTE PRINTERS AND REMOTE PUNCHES 
20 32 DCTFORMS 


Current Forms Type (Packed) 








24 36 
ALL REMOTE DEVICES 
24 36 MDCTFCS | DCTPRLEN DCTPLINE 
Function Control Sequence Remote Remote 
Printer Width |Characteristics 
28 40 | MDCTDCT 
ect i 
MDCTRCB Address of Next DCT for this Remo 
2C 44 


Device Control Table Format -- Page 8.5-17 
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Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 
O O DCTSTAT 1 DCT Status -- 


Bit Name Meaning 
0 DCTINUSE DCT is In Use. 
1 DCTDRAIN pcT is Drained. 
2 DCTHOLD DCT is Held. 


3-7 Reserved. 
O 0 DCTPCE 4 Address of Processor Control Element. 
4 4 DCTBUFAD 4 Address of Current RJE Buffer. 
8 8 DCTPSTAT 1 Remote Flags -- 
Bit Name Meaning 
0-3 Reserved for Future Use. 
4 DCTSINON DCT is Attached to Line DCT. 
5 DCTPOST I/O Complete Flag. 
6 DCTABORT Transmission was Aborted. 
7 DCTPBUF Remote has Output Buffer. 
8 8 DCTDCB 4 Address of Line Device Control Table. 
C 12 DCTEWF 4 Address of Event Wait Field. 
10 16 1 Reserved -- Must be zero. 
11 17 DCTNO 1 Remote Number. 
12 18 DCTDEVTP 1 Device Type -- 
Hex. 
Value Name Meaning 


12 DCTRJR Remote Reader. 
22 DCTRPR Remote Printer. 
32 DCTRPU Remote Punch. 

42 DCTRCON #£=Remote Console. 


Device Control Table Format -- Page 8.5-18 
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Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name 


Hex. Dec. 


13 19 
14 20 
14 20 
18 24 
20 32 
21 33 
22 34 
23 35 


DCTPCODE 


DCTFLAGS 


DCTCHAIN 
DCTDEVN 

DCTPRINT 
DCTPUNCH 
DCTPRINC 


DCTPRLIM 


564 


Bytes Field Description 
l Remote Code -- 
Bit Name Meaning 
O Reserved. 
1 DCTPTRSP Terminal Transparency. 
2 Reserved. 
3 DCTPCON Terminal Console. 
DCTPMRF Multiple-Record Feature. 
' Buffer Expansion Feature. 
4 DCTPTAB Horizontal Format Control. 
5 DCTPROG Programmable Interface. 
6 DCTPVAR Variable Length Records. 
7 DCTPBLK  Blacked Records. 
1 Operator Command Flags -- 
Bit Name Command 
e) DCTSTOP°: $2 (SSTOP) 
1 DCTDELET $C (S$DELETE) 
2 DCTRSTRT SE (SRESTART) 
3 DCTRPT SN (SREPEAT) 
4 DCTBKSP $B (SBACKSPACE) 
SF 
5 DCTHOLDJ $T...,H 
DCTSPACE $T...,C=1 
2+4 ST 
6-7 Reserved for Future Use. 
4 Address of Next Device Control Table. 
8 EBCDIC Device Name. 
1 Print Destination. 
1 Punch Destination. 
1 Priority Increment. 
1 Priority Limit. 
Device Control Table Format -- Page 8.5-19 
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Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 


20 32 DCTFORMS 2 Current Forms Type (Packed). 
22 34 2 Flags -- 
Byte 1 Bit Name Meaning 


0 DCTFSPEC Special Forms Routing. 
a4 DCTFOPER Operator Controlled Forms. 
ya | Reserved for Future Use. 


Byte 2 Bit Name Meaning 


0 DCTIDSEP Generate Separator Page/Card. 
1-7 Reserved for Future Use. 


24 36 MDCTFCS 2 Function Control Sequence Mask -- 


Bit Meaning 


Byte 1 O-3 Reserved. 
4 Reader 1 or Printer l. 
5 Reader 2, Printer 2, or Punch 7. 
6 Reader 3, Printer 3, or Punch 6. 
7 Reader 4, Printer 4, or Punch 5. 
Byte 2 O Reserved. 
1 Remote Console. 
2-3 Reserved. 
4 Reader 5, Printer 5, or Punch 4. 
5 Reader 6, Printer 6, or Punch 3. 
6 Reader 7, Printer 7, or Punch 2. 
7 Punch l. 
26 38 DCTPRLEN 1 Remote Printer Width and Remote Input Size. 
27 39. DCTPLINE 1 Remote Characteristics -- 


Bits 0-3 Adapter/Terminal Characteristics 


Bit Name Value Meaning 

@) DCTPBSC 0 STR Adapter. 
1 BSC Adapter. 

1 DCTPTRSP 0 No Transparency. 
1 Transparency. 

2 DCTPASCI @) EBCDIC Code. 
1 USASCII Code. 

3 Reserved. 


Device Control Table Format -- Page 8.5-20 
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_ Figure 8.5.5 -- REMOTE DEVICE CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


. Hex. Dec. 


ne ‘§ 


| Bits 4-7. Terminal Type 


Remote Characteristics (continued) -- 


Hex. : 

Value Name . Terminal Type 
0 DCTP2770 2770, 1009. 
1 DCTPHARD 2780, 1978. - 
2 DCTP20 360/20 Sub-Model 5. 
4 DCTP360 360/25, 30, 40, etc. 
6 . DCTP20S2 360/20 Sub Model 2. | 
8 DCTP1130 1130. 
A DCTPSYS3 System/3. 

28 40 MDCTRCB 1 Record Control Byte -- 


Bits Meaning. 


0 Always One. 


-3 Device Number. 
7 Device Type -- 


Value Device Type 


WW Wh FF 


Output Console. 
Input Console. 
Reader. 
Printer. 

Punch. 


28 ~~. 40° ~ MDCTDCT 4 Address of Next DCT for this Remote. 


Device Control Table Format -- Page 8.5-21 
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Figure 8.6.1 -- JOB QUEUE ELEMENT FORMAT 


Displacement 


Hex. Dec. 


0 0 QUEPRIO QUETYPE QUE JOBNO 


Priority Queue Type Job Number (Binary) 


4 4 QUECHAIN 


QUEFLAGS Address of Next Job Queue Element 


8 8 QUETRAK 


Disk Address of Job Control Table 


Cc 12 QUEPRTRT QUEPUNRT QUECLASS QUEREGSZ 


Print Route Punch Route QUEFORMS 





10 16 


Job Queue Element Format -- Page 8.6-1 
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Figure 8.6.1 -- JOB QUEUE ELEMENT FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. | : 


O 0 QUEPRIO 1 Queueing Priority -- 


Bits 0-3 Priority (0-15). 
Bits 4-7 Reserved. 


1 1 QUETYPE 1 Queue Type -- 
Binary 
Value Name Meaning 
1xxxxxxx QENTBY Queue Entry is In Use. 
xleccecc $XEQ Execution -- 


cccccce = Job Class - X'CO'. 
xO100000 $INPUT Input Queue. 
x0000100 $PRINT Print Queue. 
x0000010 $PUNCH Punch Queue. 
x0000000 $PURGE Purge Queue. 


2 2 QUE JOBNO 2 Job Number (Binary) 
4 4 QUEFLAGS 1 Queue Flags -- 
Bit Name Meaning 
0 QUEHOLDA Job Held (SH A) 
1 QUEHOLDL Job Held (Single Job) 
2 QUEHOLD2 Job Held (Duplicate Job Name). 
3 QUEPURGE Job Deleted. 


4-7 QUEUSECT Entry Use Count. 


4 4 QUECHAIN 4 Address of Next Job Queue Element. 
8 8 QUETRAK 4 Track Address of Job Control Table. 
G 12 QUEPRTRT 1 Print Routing: O = Local. 
n = Remote n. ° 
D 13 QUEPUNRT 1 Punch Routing: O = Local. 
, n = Remote n. 
E 14 QUECLASS 1 Sub-Class -- Unused. 
E 14 QUEFORMS 2 Forms Code (Packed). 
F 15 | QUEREGSZ 1 Region Size -- Unused. 
Job Queue Element Format -- Page 8.6-2 
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Figure 8.7.1 -- JOB INFORMATION TABLE ELEMENT FORMAT 


Displacement | 
nes 4 DYCCS SSeS Sree scares baa 


Hex. Dec. 


0 0 JITJNAME 


Job Name 





Displacement Field Name Bytes Field Description 


Hex. Dec. 


O 0 JIT JNAME 8 Job Name. 


Job Information Table Element Format ~-- Page 8.7-1 
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Figure 8.8.1 -- JOB CONTROL TABLE FORMAT 


Displacement 


Hex. Dec. 


mata 


50 80 JCTPCE 


Address of Processor Control Element 


54 84 JCTJOBNO | = SCTPRIO JCTROUTE 


Job Number (Binary) Priority Input 
Route Code 


58 88 JCTJOBEB : JCTPNAML 


Job Number (EBCDIC) Programmer's 
Name Length 


5C 92 JCTPNAME 


Programmer's Name from Job Card 


70 112 JCTJNAME 


Job Name from Job Card 





78 120 


Job Control Table Format -- Page 8.8-1 
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Figure 8.8.1 -- JOB CONTROL TABLE FORMAT (CONTINUED) 


Displacement 


Hex. 


78 


7c 


80 


84 


88 


8C 


90 


94 


98 


9C 


AO 


Dec. 


120 


124 


128 


132 — 


136 


140 


144 


148 


152 


156 


160° 


JCTACETN 


JCTROOMN 


JCTETIME 


JCTCARDS 


JCTESTLN 


~JCTLINES 


JCTESTPU 


Job Accounting Number 


Programmer's Room Number 





Estimated Execution Time 
Number of Input Cards 
Estimated Lines of Output 


Current Lines of Output 


Estimated Number of Cards to be Punched 


JCTPUNCH 


JCTLINCT 


Lines 
Per Page 


JCTFORMS 





Current Output Card Count 


JCTCPYCT | JCTLOG -JCTFLAGS 


Print | Log Option | Miscellaneous 
Copy Count | Switch Flags 


Job Print Forms 


Job Control Table Format -- Page 8.8-2 
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Figure 8.8.1 -~- JOB CONTROL TABLE FORMAT (CONTINUED) 


Displacement 


Hex. 


AO 


A4 


A8 


AC 


BO 


B4 


~ BB 


BC 


Co 


C4 


C8 


Dec. 


160 


164 


168 


172 


180 


184 


188 


192 


196 


200 





JCTRDROF 


Job Punch Forms 


JCTPRICT 


Current Number of Lines Printed 


JCTPAGCT 


Current Number of Pages Printed 


JCTPUNCT 


Current Number of Cards Punched 


JCTRDRON . 


Reader Sign-On Time 





Reader Sign-Off Time 


JCTXEQON 


Execution Sign-On Time 


JCTXEQOF 


Execution Sign-Off Time 


JCTPRTON 


Printer Sign-On Time 


JCTPRTOF 


Printer Sign-Off Time 
! 


Job Control Table Format -- Page 8.8-3 
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Figure 8.8.1 -- JOB CONTROL TABLE FORMAT (CONTINUED) 
Displacement 

Hex. Dec. 

C8 200 ~ JCTPUNON 


Punch Sign-On Time 


CC 204 - JCTPUNOF 


Punch Sign-Off Time 


DO 208 © JCTPRC 
Checkpoint Checkpoint Checkpoint PDDB Displacement 
Flags Copy Count 
D4 212 
Checkpoint PDDB Page Count Checkpoint Total Line Count 
D8 216 | 
Checkpoint Total Line Count | Checkpoint Total Page Count 
(continued). — | 
DC 220 Checkpoint Total Page Count 
(continued) oe 
JCTRDRTR | ee First Reader Track 
E0 224 ' JCTCYSAV ~ 


Input File Track Allocation Bit Map Save Area 


— SCTCYMXM 


Maximum MTTR for Current Track Group 


JCTMTTR 


Last MTTR Allocated 





Job Control Table Format -- Page 8.8-4 
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Figure 8.8.1 -- JOB CONTROL TABLE FORMAT (CONTINUED) 


Displacement | 
Nip me ee em Sotesiesleatestetentesteaietetectetetestestetes 4: DYCES. See sees ossh eae ese ser H t= 
Hex. Dec. . -% 


_JCTCYMAP 


Variable Length Track Allocation Bit Map 


JCTACCT 


132-Byte Job Accounting Information Area | 


JCTPDDB © 
JCTLPDDB 


HASP System Log PDDB 


JCTSPDDB 


System Message Block (SMB) PDDB 


Peripheral Data Definition Block (PDDB) Area 





b 


Job Control Table Format -- Page 8.8-5 
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Figure 8.8.1 -- JOB CONTROL TABLE FORMAT (CONTINUED) 


‘Displacement Field Name Bytes 


Hex. 
50 
50 
54. 
56 


57 


58 
5B 
5C 
70 
78. 
7c 
80 
84 
88 
8C 
90 
94 


98 


99 - 


OR 


80 
80 
84 
86 


87 


88 
91 
92 

112 

120 

124 
128 
132 
136 
140 
144 
148 
152 


153 


154 


JCTID 


JCTPCE 


JCTJOBNO 


JCTPRIO 


JCTROUTE 


JCTJOBEB 


JCTPNAML 


JCTPNAME 
JCTINAME 


JCTACCTN 


JCTROOMN 


JCTETIME 


JCTCARDS 
JCTESTLN 
JCTLINES 
JCTESTPU 
JCTPUNCH 
SCTLINCT 
SCTCPYCT 
JCTLOG 


Field Description 


1 JCT paeaeerestien.2e X'FF!. 

4 Address peeeeceisos Control Element. 
2 Job Number (Binary). 

l Priority from /*PRIORITY Card. 


Local. 
Remote n. 


1 Route Code of Input Device: 0 
| n 


3 Job Number (EBCDIC). 


1 Length of Programmer's Name. 


20 Programmer's Name from Job Card. 


8 | Job Name from Job Card. 

4 Job ACéounting Number. 

4 Programmer's Room Number. 

4 Estimated Execution Time. 

4 Number of Input Cards. 

4 peas Lines of Output. 

4 Generated Lines of Output. 

4 Estimated Number of Cards to be Punched. 
4 Number of Output Cards Generated. 
1 ‘Lines per Bauee 

a Number of Copies of Print. 

1 Log Option er ee 


'-EBCDIC | 
Value Meaning 


L Produce HASP SYSTEM LOG. 
N Do not Produce HASP SYSTEM LOG. 


Job Control Table Format -- Page 8.8-6. 
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Figure 8.8.1 -- JOB CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name 


Hex. 


Cerner 


9B 


A8 
AC 
BO 
B4 
B8 
BC 


CO 


DO 


Dec. 





155 


160 
164 
168 
172 
176 
180 
184 
188 
192 
196 
200 
204 
208 
220 


224 


JCTFLAGS 


JCTFORMS 


JCTPRICT 
JCTPAGCT 
JCTPUNCT 


JCTRDRON 


JCTRDROF 


JCTXEQON 
JCTXEQOF 
JCTPRTON 


JCTPRTOF 


~ JCTPUNON 


JCTPUNOF 
JCTPRC 
JCTRDRTR 


JCTCYSAV 


JCTCYMXM 
JCTMTTR 


JCTCYMAP 


Bytes Field Description 
l Miscellaneous Flags -- 
Bit Name Meaning 
0 JCTDSRT Processing Special Forms. 
-L~7 Count of Input Data Sets 
SPOOLed by HASP. 
4 Job Print Forms. 
4 356: Punch Forms: 
4 Number of Lines Printed. 
4 Number of Pages Printed. 
4 Number of Cards Punched. 
4 Reader Sign-On Time. 
4 Reader Sign-Off Time. 
4 Execution Sign-On Time. 
4 Execution Sign-Off Time. 
4 Print Sign-On Time. 
4 Print Sign-Off Time. 
4 Punch Sign-On Time. 
4 Punch Sign-Off Time. 
14 Print Checkpoint Element. 
4 First Reader Track. 
Variable Length Input File 
Track Allocation Bit Map Save Area. 
4 Maximum MTTR for saree Track Group. 
4 Last MTTR Allocated. 
Variable Length Track Allocation Bit Map. 
Job Control Table Format -- Page 8.8-7 
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Figure 8.8.1 -- JOB CONTROL TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. 


JCTACCT 132 Job Accounting Information Area. 
JCTPDDB Peripheral Data Definition Block (PDDB) Area. 
JCTLPDDB 5 HASP System Log PDDB. 
JCTSPDDB 5 System Message Block (SMB) PDDB. 
Job Control Table Format -- Page 8.8-8 
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Figure 8.9.1 -- TRACK EXTENT DATA TABLE FORMAT 


Displacement 


Hex. Dec. 





0 0 
MTTR For Most Recent SEXCP on this Module 
4 4 TNTC 
Number of Tracks per Cylinder on this Device 
8 8 TNMD | TNRT 
DEB Extent Number Number of HASP 
(times 256) Buffers per Track 
C 12 TNGE TNTG 
Number of Groups/Extent Number of Tracks/Group 
10 16 TNMO : TNMB 
Offset of this Map Number of Bytes 
from First Map in this Map 
14 20 


Displacement Field Name Bytes Field Description 
Hex. Dec. | 


0 0 TNCH 4 MTTR for Most Recent SEXCP on this Module. 
4 4 TNTC 4 Number of Tracks per Cylinder on this Device. 
8 8 TNMD 2 DEB Extent Number (times 256). 
A 10 TNRT 2 Number of HASP Buffers per Track. 
Cc 12 TNGE 2 Number of Track Groups per Extent. 
E 14 TNTG 2 Number of Tracks per Track Group. 
10 16 TNMO 2 Offset of This Map from First Map. 
12 18 - TNMB 2 sees of Bytes in This Map. 
Track Extent Data Table Format -- Page 8.9-1 
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Figure 8.10.1 -- TIMER QUEUE ELEMENT 
Displacement 
Po Sane See ee as * DYCES SSeSreon esses Seas e Sn 
Hex. Dec 
0 0 ICHAIN 
Address of Next HASP Timer Queue Element 
4 40 
Specified Interval 
8 8 IPOST 
Address of Event Wait Field to be Posted 
C 12 


Displacement Field Name Bytes Field Description 


Hex. 


Dec. 
0 ICHAIN 4 Address of Next HASP Timer Queue Element. 
4 — ITIME | 4 Timer Interval. 
8 IPOST 4 


Byte l Flag Byte -- 


Pst AIaluan Meering 





0 6) Timer Interval has not Expired. 
1 Timer Interval has Expired. 
1-7 Reserved. 


Bytes 2-4 Address of Event Wait Field to be Posted. 


Timer Queue Element Format -- Page 8.10-1 
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Figure 8.11.1 -- OVERLAY TABLE FORMAT 


Displacement 


Hex. Dec. 









: : | oteenes Address of Resident Overlay Module 
ereesl? RESERVED OLETRAK Relative TTR 
&DEBUG = YES 


0 0 OTBNAME 


Overlay Module Name (Last Four Characters) 


, =e Dleenes Address of Resident Overlay Module 


OTBPRIO RESERVED OTBTRAK = Relative TTR 


8 8 OTBCALLS OTBLODS 


Count of PCE Requests Count of Times Loaded 





Overlay Table Format -- Page 8.11-1 
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Figure 8.11.1 -- OVERLAY TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes 


Hex. Dec. 


0 0 OTBADDR 4 
Byte l 
Bytes 2-4 
0 0 ‘ OTBPRIO 1 
1 1 1 
2 2 OTBTRAK 2 
0 0 OTBNAME 4 
g g OTBCALLS 2 
A 10 -QOTBLODS | 2 


Field Description 


Address of Resident Overlay Module. 
X'FF'. 


Addressability Address of Resident 
Overlay Module -- Assembly Origin - X'50'. 


Priority of Overlay Module. 
Reserved for Future Use. 


Relative Track and Record Address of 
Overlay Module. 


Last Four Characters of Overlay Module Name. 


Number of Times This Overlay Module 
was Requested. 


Number of Times This Overlay Module 
was Loaded. 


Overlay Table Format -- Page 8.11-2 
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Figure 8.12.1 -- DATA DEFINITION TABLE FORMAT 


Displacement 





SSS SSS See 4 DY CES Sree sesSs = <SeSeses eee =e 
Hex. Dec. 
0 0 |  DDBCHAIN 
Address of Next Data Definition Table 
4 4 DDBTYPE DDBUNIT 
Data Set Type | Unit Address (EBCDIC) 
8 8 DDBSTATI DDBSTAT2 DDBUFPTR 
(XS) | 
Status Byte 1} Status Byte 2 Current Buffer Pointer 
C 12 DDBPBUF 
Address of Primary Buffer or TTR 
10 16 DDBSBUF Address of Secondary Buffer (Input) 
DDBFORMS 
Special Forms Type (Output) 
18 24 DDBTTR 
Next Track Address (Input Data Sets) 
First Track Address (Output Data Sets) 
1c 28 DDBCOUNT 
Output Record Count , RESERVED 
20 32 DDBPCE 
Address of Processor Control Element 
24 36 


Data Definition Table Format -- Page 8.12-1 
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Figure 8.]2.1 -- DATA DEFINITION TABLE FORMAT (CONTINUED) 
Displacement Field Name Bytes Field Definition 
Hex. Dec. 
0 0 DDBCHAIN 4 Address of Next Data Definition Table. 
4 4 DDBTYPE 1 Data Set Type -- 
Hex 
Value Name Data Set Type 
O01 XSPROUTE Special Route SYSOUT. 
O2 XPRIDDB- Print. 
O04  XPUNDDB Punch. 
08 XPLOTDDB Plot. 
10  XLOGDDB Log. 
40 XNULLDDB Dummy (Null). 
80 XINDDB Input. 
5 5 DDBUNIT 3 Unit Address (EBCDIC). 
—8 8 DDBSTATL =—sssa1 Status Byte l -- 
| (XS) | | 
. Bit Name Meaning 
0 XSEOD End of Data on Secondary. 
1 XSIOA I/O Active on Secondary. 
2 XSTO I/O Required on Secondary. 
3 XNSB No Secondary Buffer. 
4 XPEOD End of Data on Primary. 
5 XPIOA I/O Active on Primary. 
6 XPIO T/O Required on Primary. 
7 XNPB No Primary Buffer. 
9 9 DDBSTAT2 } Status Byte 2 -- 
Bit Name Meaning 
0 XACT Action Required on This DDT. 
1 Reserved for Future Use. 
2 XLOGHEAD Log Title Switch. 
3 XOPEN DDT has been Used. 
4 XUCB Allocatable UCB Exists. 
5 XIOC I/O Error on Read. 
6 XROLL Roll Output Buffer. 
7 XTERM Terminate DDT. 
Data Definition Table Format -- Page 8.12-2 
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Figure 8.12.1 -- DATA DEFINITION TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 


Hex. Dec. 
A 10 DDBUFPTR 2 Current Displacement of Data in 
Primary Buffer. 
C 12 DDBPBUF 4 Address of Primary Buffer -- Or TTR. 
1f No Primary Buffer. 
10 16 DDBSBUF 4 Address of Secondary Buffer (Input Only). 
10 16 DDBFORMS 8 Special Forms Type (Output Only). 
18 24 DDBTTR 4 Input: Next Track Address. 
Output: First Track Address. 
1c 28 DDBCOUNT 2 Output Record Count. 
1lE 30 2 Reserved for Future Use. 
20 32 DDBPCE 4 Address of Processor Control Element. 


Data Definition Table Format -- Page 8.12-3 
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Figure 8.13.1 -- PARTITION INFORMATION TABLE FORMAT 


Displacement | | ee ae 
Hex. Dec. | 
0 0 PITSTAT  PITICLAS . PITPATID 


Status Byte Initiator | Logical Partition 
3 Class Identification 


4 4 PITSIZE PITPRIO 


Logical Partition Size Logical Partition PRTY 





WITH EXECUTION JOB BATCHING 


















8 8 PITBECB 
Batching Program Frozen ECB Chain 
C 12 PITBJST 
Address of Batching Program TCB 
10 16 PITBCLAS PITBUNIT 
Batching Program Input Unit 
14 20 i PITBUCBA PITCLASS 


Batching Input UCB Address 


Variable Number of Logical Partition Classes 





Partition Information Table Format -- Page 8.13-1 
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Figure 8.13.1 -- PARTITION INFORMATION TABLE FORMAT (CONTINUED) 
Displacement ao 


H Hex. Dec. 


' WITHOUT EXECUTION JOB BATCHING 


8 8 PITCLASS 





Variable Number of Logical Partition Classes 





Partition Information Table Format -- Page 8.13-2 
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Figure 8.13.1 -- PARTITION INFORMATION TABLE FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. 


0 0 PITSTAT 1 Status Byte -- 


Bit Name Meaning 





0 PITHOLDA PIT is Drained (SP I). 

1 PITHOLDL PIT is Drained ($P In). 

2 PITBUSY Partition Busy Indicator. 

3 PITIDLE PIT Idle Message Switch. 
4-6 Reserved for Future Use. 

7 PITLAST Last PIT Indicator. 


1 1 PITICLAS 1 O/S Initiator Class. 

2 2 PITPATID 2 pegiead Partition Identification. 

4 4 PITSIZE 2 Logical Partition Size (Unused). 

6 6 PITPRIO 2 Logical Partition PRTY. 

8 —~8 PI-TBECB 4 Batching Program Frozen ECB Chain. 

C (12 PITBUST 4 Address of Batching Program TCB. 

10 16 PI TBCLAS 1 Active Batching Class. 

11 17 PITBUNIT 3 Batching Program Input Unit. 

14 20 PITBUCBA 2 Batching Input Unit Control Block (UCB) 
Address. 

PITCLASS Variable Number GF Logical Partition 
Classes. 
Partition Information Table Format -- Page 8.13-3 
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Figure 8.14.1 -- MESSAGE ALLOCATION CONTROL BLOCK 


Displacement 


Hex. Dec. 


0 0 MSAMTTR 


Base SPOOL Record Pointer 


4 4 MSARPTRK | MSABITS 


Number of Records/Track 


Variable Length Allocation Bit Map 





Displacement Field Name Bytes Field Description 
Hex. Dec. | 


0 0 MSAMTTR 4 Base SPOOL Record Pointer. 


4 4 MSAPTRK | 2 Number of Records/Track. 
6 6 MSABITS Variable Length Allocation Bit Map. 


” 


Message Allocation Control Block Format os Page 8.14-1 
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Figure 8.15.1 -- DATA BLOCK FORMAT 


Displacement 


Hex. Dec. 


50 80 HDBNXTRK 


Track Address of Next Data Block 


54 84 HDBSTART 
Control 
Record Byte 
Length 


Variable Length Data Area 


Record Control 
Length Byte 


Variable Length Data Area 


Control 
Byte 


Variable Length Data Area 


Block 
Terminator 


] Unused » ] 





Data Block Format -- Page 8.15-1l 
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Figure 8.15.1 -- DATA BLOCK FORMAT (CONTINUED) 


Displacement Field Name Bytes Field Description 
Hex. Dec. | 


50 80 HDBNXTRK 4 Track Address of Next Data Block. 
54 84 HDBS TART | Start of Data Block. 
Record 1 Length of Data Area (0-254). 
Length | 
Control - 1 Control Byte -- 
Byte 


Input Data Sets 


Hex. . 
Value Meaning 


OO . Normal Record. 

03 Internally Generated Card. 
04 HASP Control Card. 

13 ITllegal HASP Control Card. 
19 Last JCL Card. 

73 Dummy Track Address Record. 


Print Data Sets -- Carriage Control. 


Punch Data Sets -- Stacker Select. 
Data | Variable Length Data Area. 
Area 
Block Record Length of 255 (X'FF'). 
Terminator 


Data Block Format -- Page 8.15-2 
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